Hello Rainer,
Please find some inline comments below.
--Gordon
On 30/11/2012 11:02 AM, Rainer Kwesi Schweigkoffer wrote:
> 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.
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.
>
>>> 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...
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.
>
> Concerning the copy operation, I think, I have not fully understood the
> copied entity's state and identity.
What parts are unclear?
>
> 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.
>
> 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.
>
>