Hello Pinaki and others,
@NamedSubgraph is reusable within the same NamedEntityGraph
definition as references from the named attribute nodes are based on name.
However, we will simply have to disagree on which pattern is easier
to maintain and read.
--Gordon
On 04/12/2012 11:48 AM, Pinaki Poddar wrote:
>
> > 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.
>
> "easily" it is not. Imagine if the use case said "10-level down"!
>
> The point is embedding all related entity graphs in a single entity is
> not an elegant solution. @SubGraph does not allow reuse and makes
> things unnecessarily verbose. For example, if Address is to be fetched
> with many other entities, then each entity has to annotate that
> subgraph. The elgant solution is to root every subgraph to its own
> entity + allow inclusion of subgraphs by name in other entities.
>
>
>
>
> Regards --
>
> Pinaki Poddar
> Chair, Apache OpenJPA Project http://openjpa.apache.org/
> JPA Expert Group Member
> Application & Integration Middleware
>
>
>
>
>
>
> Inactive hide details for Gordon Yorke ---12/03/2012 05:25:49
> PM---Hello Pinaki, > Let us say we have two domian entities:
> FileGordon Yorke ---12/03/2012 05:25:49 PM---Hello Pinaki, > Let us
> say we have two domian entities: File and Directory. Directory
>
> From: Gordon Yorke <gordon.yorke_at_oracle.com>
> To: jsr338-experts_at_jpa-spec.java.net
> Date: 12/03/2012 05:25 PM
> Subject: [jsr338-experts] Re: Proposal for EntityGraphs, fetch plans,
> etc...
> ------------------------------------------------------------------------
>
>
>
> 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.
>
> The point 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>_
> <mailto:kwesi_at_sap.com>
> To: Gordon Yorke _<gordon.yorke_at_oracle.com>_
> <mailto:gordon.yorke_at_oracle.com>,
> _jsr338-experts_at_jpa-spec.java.net_
> <mailto: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_
> <mailto: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.
>
>
>