users@jpa-spec.java.net

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

From: Linda DeMichiel <linda.demichiel_at_oracle.com>
Date: Fri, 07 Dec 2012 13:10:09 -0800

Hi Rainer, all

On 12/4/2012 5: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, and I think this argues for the entity graph approach. For example,
as an employee, I don't want my home address exposed (or necessarily
loaded), although exposing my work address is fine. As a customer, I
don't want my work address exposed/loaded. Similarly for home/work/cell
phone numbers.

best regards,

-Linda


>>>>> 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.
>
> 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.
>
>