Date: Tue, 4 Dec 2012 07:48:16 -0800
> 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
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>
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.
(image/gif attachment: graycol.gif)