users@jpa-spec.java.net

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

From: Pinaki Poddar <ppoddar_at_us.ibm.com>
Date: Mon, 3 Dec 2012 09:21:46 -0800

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








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.



graycol.gif
(image/gif attachment: graycol.gif)