Hi Gordon, all,
Gordon Yorke, am 30 Nov 2012 hast Du um 16:52 zum Thema "[jsr338-
experts] Re: Proposal for EntityGraphs, f" geschrieben :
> > 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.
> For operations like detach() the user may not want to force the data to
> be loaded but just detach the entity tree as is. Passing a FetchGroup
> in that case would be counter intuitive. We may also find uses for the
> entity graphs separate from EntityManager operations in which case
> FetchGroup would not be appropriate. It is better to define a more
> flexible design now.
Well, I am not sure whether I am getting you right here.
If a user wants to detach an entity tree just as it is, they may call
detach() without providing an entity graph.
Once an entity or a set of entities has been detached, however, often
the question is what part of the entities may be trusted to have been
loaded. In JPA 2.0 we have worked out the isLoaded() utility as per
section 9.8.1 (then 9.7.1) for that. Being able to supply an entity
graph along with a detach() call may give the user a chance to declare
what is expected to have been loaded.
One step further, setting entity graphs as properties of a persistence
context may enable the user to define in general what should have been
loaded when entities get detached from the persistence context (e.g.
due to end of life of the context).
> > 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...
> My concern with this pattern is readability. Users must scan through
> the entire object model to determine what is in an entity graph and what
> will be loaded or what is missing for their case. This pattern also can
> get quite complicated quickly when there are multiple "contracts" in
> place for a particular entity.
Actually, this concern works both ways: With the given proposal, if a
user wants to understand what views are available of a particular
entity, all entity graphs throughout both the entire object model and
the coding must be scanned for.
> > Concerning the copy operation, I think, I have not fully understood the
> > copied entity's state and identity.
> What parts are unclear?
When e.g. an employee, as per the example in the proposal, gets copied,
what is identity and state of the resulting copy?
> > 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.
> a loadgraph is just a shortcut for users that allows them to specify
> what relationships should be loaded without requiring all mapping
> configured EAGER attributes to be specified.
Maybe, a more descriptive naming might be of some help here; fetchgraph
and loadgraph seem to me too much like synonyms (overridegraph vs.
modifygraph?).
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.