Hello Rainer and others,
Comments below:
--Gordon
On 04/12/2012 9:25 AM, Rainer Kwesi Schweigkoffer wrote:
> Hi Gordon, all,
>
> thanks for your quick response. Please find my comments inline.
>
> Gordon Yorke, am 3 Dec 2012 hast Du um 21:39 zum Thema "[jsr338-
> experts] Re: Proposal for EntityGraphs, f" geschrieben :
>
>>>> 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.
> If it is Address you mention, one could imagine that Address might be
> related to different entities such as e.g. Employee (home and work
> address), Customer (billing and shipping address), Company and many
> more. For each of them there might exist a named graph with the
> respective entity as root, that may affect loading of Address instances
> via one of its subgraphs. Even different occurrences of Address within
> the same entity graph (e.g. home address and work address) might yield
> different load strategies. Plus, there might be dynamically created
> entity graphs affecting Address. That's what I meant.
Yes, but this is always the case. At any point unless the application
is tracking every access to the Address there is no way to know the
state of the Address without interrogating the Address object. The only
guarantee you have is when an entity graph is applied. With this
proposal because the entity graph is defined as single block it can be
inspected in place and it will be clear what affect this entity graph
will have on the Address instances in the result or the persistence
context. There's no need for the developer to search out the elements
of the entity graph throughout the domain model and correlate
relationships to determine how an entity graph that is being used for a
particular operation will impact the result.
>
>>>>> 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.
> Actually, with state I was referring to detached vs. managed vs. new.
The copied entity instances would be detached and possibly new if new
instances were copied.
>
> Kind 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.
>
>