[jpa-spec users] [jsr338-experts] Re: Proposal for EntityGraphs, fetch plans, etc...

From: Gordon Yorke <>
Date: Mon, 03 Dec 2012 21:39:38 -0400

Hello Rainer and all,
   thank you for the update, comments inline below.

On 03/12/2012 2:37 PM, Rainer Kwesi Schweigkoffer wrote:
> 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.
Yes but what is detached is based on the statically defined mapping
cascade types. The purpose of the entity graph is to dynamically
provide a template for the operation. In the future we could easily use
defined entity graphs to control the detach operation.
> 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.
Perhaps, but the user may want to setup a detach template without
requiring that all of the data be loaded. There's also the possibility
to apply the load and detach operations separately but use the same
entity graph.
> 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).\
That is an option that is not precluded by the proposed entity graphs.
it's just a matter of using the entity graph provided by the user as a
default fetch graph for this persistence 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.
No because the entity graph is defined at the entity level and the
entity graph only applies to the entity where it is defined. So to view
how queries for Address will load Address and related entities one only
has to look at the Address entity. There would be no need to search the
related entities to see how the Address query will access that data.
>>> 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?
The copy has the persistence identity of the copied entity and it's
version but only has the state that the entity graph template designated
should be copied.
>>> 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?).
yes, perhaps the names should be improved.
> 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
> 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.