Hello Pinaki,
> Let us say we have two domian entities: File and Directory. Directory
> extends File. Every File (except the root) has a parent which is a
> Directory. A directory can have zero or more Files, some of which can
> be directories.
>
> Now a user wants to say: "Query for a directory named 'X' and get me
> all children 3 level down"
>
> How is that "3-level down" expressed in the proposal?
The depth could easily be restricted through the definition of a finite
set of SubGraphs.
@NamedEntityGraph(
attributeNodes={_at_NamedAttributeNode("child","level1")},
subGraphs={
@NamedSubGraph(
name="level1",
attributeNode={_at_NamedAttribureNode("child", "level2")},
),
@NamedSubGraph(
name="level2",
attributeNode={_at_NamedAttribureNode("child")},
)}
)
> The aspect that I am not much comfortable is the SubGraph concept.
> My view is each entity describes subgraphs that refer to its own
> properties and includes subgraphs that are rooted in other entities.
> Such a mechanics will be able to generate a large variety of
> combinations. The same capability will become too verbose if we tend
> to define these combinations in a single root entity through the
> SubGraph annotations as I understand of the proposal.
Thepoint of defining the entire entity graph in one spot is to make the
definition very clear while providing flexibility.
--Gordon
On 03/12/2012 1:21 PM, Pinaki Poddar wrote:
>
> Hello Rainer et al,
> The specification could be also viewed as a syntax of describing
> subgraphs of the entire graph of a domain model as described by the
> Java language itself. These subgraphs are then attached to the
> persistence operations such as query, merge or detach. In that sense
> they are an elaborate mechnics of how a typical persietence operation
> will cascde. In this view, I do think the proposal's usage of
> "EntityGraph" as a better moniker than "FetchPlan" - though it may be
> more common term as the concept originally appeared in the context of
> fecthing of objects and their relations.
>
> The aspect that I am not much comfortable is the SubGraph concept.
> My view is each entity describes subgraphs that refer to its own
> properties and includes subgraphs that are rooted in other entities.
> Such a mechanics will be able to generate a large variety of
> combinations. The same capability will become too verbose if we tend
> to define these combinations in a single root entity through the
> SubGraph annotations as I understand of the proposal.
>
> On a specifc issue of what are the extra qualifiers on the edges of
> such subgraphs:
> a) Some of the qualifiers such as lock mode as these edges are
> traversed does not control topology of the subgraph but merely adds
> qualities to the persistent operatons that cascade along the edges.
> They are nice to have.
> b) filters (as, say, in xpath) could be considered -- but may be at
> a later phase.
> c) recursion depth as a limit on the number of times a edge can be
> traversed. This recursion depth seems to be essential.
>
> But let me understand the proposal on that aspect better through the
> following use case:
>
> Let us say we have two domian entities: File and Directory. Directory
> extends File. Every File (except the root) has a parent which is a
> Directory. A directory can have zero or more Files, some of which can
> be directories.
>
> Now a user wants to say: "Query for a directory named 'X' and get me
> all children 3 level down"
>
> How is that "3-level down" expressed in the proposal?
>
>
>
> Regards --
>
> Pinaki Poddar
> Chair, Apache OpenJPA Project http://openjpa.apache.org/
> JPA Expert Group Member
> Application & Integration Middleware
>
>
>
>
>
>
> Inactive hide details for "Rainer Kwesi Schweigkoffer" ---11/30/2012
> 07:15:59 AM---Hi Gordon, Pinaki, all Gordon Yorke, am 29 N"Rainer
> Kwesi Schweigkoffer" ---11/30/2012 07:15:59 AM---Hi Gordon, Pinaki,
> all Gordon Yorke, am 29 Nov 2012 hast Du um 14:29 zum Thema "[jsr338-
>
> From: "Rainer Kwesi Schweigkoffer" <kwesi_at_sap.com>
> To: Gordon Yorke <gordon.yorke_at_oracle.com>,
> jsr338-experts_at_jpa-spec.java.net, Pinaki Poddar/Dallas/IBM_at_IBMUS
> Date: 11/30/2012 07:15 AM
> Subject: Re: [jsr338-experts] Re: Proposal for EntityGraphs, fetch
> plans, etc...
>
> ------------------------------------------------------------------------
>
>
>
> 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.
>
> > > 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...
>
> Concerning the copy operation, I think, I have not fully understood the
> copied entity's state and identity.
>
> 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.
>
> 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.
>
>
>