Hi Gordon, Pinaki, all
Gordon Yorke, am 29 Nov 2012 hast Du um 14:29 zum Thema "[jsr338-
experts] Re: Proposal for EntityGraphs, f" geschrieben :
> > Few comments:
> > 1. The naming could be FetchPlan/FetchAttribute etc as they are more
> > commonly used than NamedEntityGraph etc.
> >
> But the EntityGraph is used for more than just FetchPlans. Naming it
> FetchPlan would give the wrong focus.
I have always been thinking of the artefact as a contract between
provider and consumer about the attributes that have to be loaded. You
may use these load contracts for find() and queries, but I could also
imagine them with refresh() and detach() or even as properties of a
persistence context. When you merge entities, you inform the jpa
provider about the load contract you have received them under.
> > 2. The need for a SubGraph may not be required. If every
> > FetchGroup/NamedEntityGraph defined/rooted in entity type X can
> > include FetchGroup(s) defined in other entity type Y, then a separate
> > definition of SubGraph would not be necessary.
> >
> With this pattern it is very difficult for users to track the contents
> of an entity graph as the details would be spread out all over the
> object model. With the proposed pattern the information is in one
> location and easy to maintain.
This depends a bit on your perspective on the artefact, I would say.
You may either see it as an autonomous construct that overrules the
entity definition, or you could say, an entity offers views of itself
that contribute to different contracts.
By the way, I have also been thinking whether these
EntityGraphs/FetchPlans/LoadContracts might be designed in a similar
way as bean validation is, such that you may annotate an entity
attribute with something like
@Eager(contracts=AccountantView.class)
or
@Load(contracts=AccountantView.class)
where AccountantView is a tagging interface. Avowedly, providing a
dynamic way to create such artefacts might become difficult...
Concerning the copy operation, I think, I have not fully understood the
copied entity's state and identity.
Besides, I find the coexistence of properties fetchgraph and loadgraph
a bit confusing and would prefer if a decision could be made for just
one of them.
Best regards
Rainer
---
Rainer Schweigkoffer SAP AG Walldorf
Regulatory Compliance TIP Core JI
Core Java Infrastructure Dietmar-Hopp-Allee 16
Technology & Innovation Platform D-69190 Walldorf
Building 3, F.3.14 phone: +49 6227 7 45305
rainer.schweigkoffer_at_sap.com fax: +49 6227 7 821177
Sitz der Gesellschaft/Registered Office: Walldorf, Germany
Vorstand/SAP Executive Board: Werner Brandt, Lars
Dalgaard, Luisa Deplazes Delgado, Bill McDermott (Co-CEO),
Gerhard Oswald, Vishal Sikka, Jim Hagemann Snabe (Co-CEO)
Vorsitzender des Aufsichtsrats/Chairperson of the SAP
Supervisory
Board: Hasso Plattner
Registergericht/Commercial Register Mannheim No HRB 350269
Diese E-Mail kann Betriebs- oder Geschaeftsgeheimnisse
oder sonstige vertrauliche Informationen enthalten.
Sollten Sie diese E-Mail irrtuemlich erhalten haben, ist
Ihnen eine Verwertung des Inhalts, eine Vervielfaeltigung
oder Weitergabe der E-Mail ausdruecklich untersagt. Bitte
benachrichtigen Sie uns und vernichten Sie die empfangene
E-Mail. Vielen Dank.
This e-mail may contain trade secrets or privileged,
undisclosed, or otherwise confidential information. If you
have received this e-mail in error, you are hereby
notified that any review, copying, or distribution of it
is strictly prohibited. Please inform us immediately and
destroy the original transmittal. Thank you for your
cooperation.