Date: Tue, 18 Dec 2012 15:03:08 -0800
> since the application may not necessarily want to detach those entities
from the persistence context.
a simple solution is to add an option to detach that leaves the original
entities in the persistence context.
Regards --
Pinaki Poddar
Chair, Apache OpenJPA Project http://openjpa.apache.org/
JPA Expert Group Member
Application & Integration Middleware
From: Linda DeMichiel <linda.demichiel_at_oracle.com>
To: jsr338-experts_at_jpa-spec.java.net
Date: 12/18/2012 02:37 PM
Subject: [jsr338-experts] Re: Proposal for EntityGraphs, fetch plans,
etc...
On 12/18/2012 2:00 PM, Pinaki Poddar wrote:
> Gordon,
> As long as an industry-level specification is concerned, "time
constraints" should never be a valid argument for
> introducing an alternative that is difficult to justify later. If time is
a constraint, then it is better to hold back
> the feature for later releases.
In general, I agree with your point regarding the factor of time
constraints.
However, I do not see detach graphs as an alternative to copy graphs, since
the application may
not necessarily want to detach those entities from the persistence context.
> The users need for a subgraph to another tier is adequately addressed
within detach-modify-merge cycle of JPA
> programming model, which is a significant and useful departure from
remotable EJB programming model of earlier days.
> From that viewpoint, introduction of a copy() function is a step
backwards and, as mentioned in this thread, may
> promote a "dangerous" programming model.
>
>
>
> 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/18/2012 01:22:20 PM--- Hello
Pinaki and others, - detach(EntityGraph) is
> functionGordon Yorke ---12/18/2012 01:22:20 PM--- Hello Pinaki and
others, - detach(EntityGraph) is functionality we
> should introduce but the
>
> From: Gordon Yorke <gordon.yorke_at_oracle.com>
> To: jsr338-experts_at_jpa-spec.java.net
> Date: 12/18/2012 01:22 PM
> Subject: [jsr338-experts] Re: Proposal for EntityGraphs, fetch plans,
etc...
>
>
------------------------------------------------------------------------------------------------------------------------
>
>
>
> Hello Pinaki and others,
>
> - detach(EntityGraph) is functionality we should introduce but the
semantics are more complicated than copy() and should
> be deferred because of time constraints.
> - the need derives from user requests. Users wish to create copies of a
graph of entities for many different reasons and
> currently they must implement this functionality themselves.
> - I believe we are discussing copy() separately from the discussions on
EntityGraphs and copy() exists as its own
> functionality but copy() is enabled through EntityGraphs so the features
are related and hence introduced at the same time.
>
> --Gordon
>
> On 18/12/2012 2:15 PM, Pinaki Poddar wrote:
>
>
> > I find the programming model quite error prone and dangerous.
> +1
>
> A separate copy() function does seem to add redundant complexity.
As such, creating copies often is the beginning
> of all sorts of anti-patterns. If the need for a copy() is strongly
felt, then
> a) detach() with an option to leave the objects in the persistence
context can be considered to achieve similar
> functionality.
> b) the need for a separate copy() should be articulated more
clearly
> c) in any case, the proposal for a copy() should be tabled
separately from EntityGraph specification.
>
>
>
> Regards --
>
> Pinaki Poddar
> Chair, Apache OpenJPA Project _http://openjpa.apache.org/_
> JPA Expert Group Member
> Application & Integration Middleware
>
>
>
>
>
>
> Inactive hide details for Emmanuel Bernard ---12/17/2012 09:12:47
AM---OK I get it now. To be honest I am quite
> uncomfortable wEmmanuel Bernard ---12/17/2012 09:12:47 AM---OK I
get it now. To be honest I am quite uncomfortable
> with such a feature. Does everyone
>
> From: Emmanuel Bernard _<ebernard_at_redhat.com>_ <
mailto:ebernard_at_redhat.com>
> To: _jsr338-experts_at_jpa-spec.java.net_ <
mailto:jsr338-experts_at_jpa-spec.java.net>
> Date: 12/17/2012 09:12 AM
> Subject: [jsr338-experts] Re: Proposal for EntityGraphs, fetch
plans, etc...
>
>
------------------------------------------------------------------------------------------------------------------------
>
>
>
> OK I get it now.
>
> To be honest I am quite uncomfortable with such a feature. Does
everyone
> really think that this feature is a must have?
>
> I imagine that the use case you have in mind is to pass this copied
> object graph to another serialization or traversal framework that
would
> otherwise traverse the JPA guards like there is no tomorrow.
>
> Our experience with Bean Validation has shown that handling guards
is
> extremely easy and that the necessary contract to make a
traversal /
> serialization framework aware of these is quite simple _
>
__https://github.com/beanvalidation/beanvalidation-api/blob/master/src/main/java/javax/validation/TraversableResolver.java_
>
> The solution proposed here (the copy) forces to copy an object
graph
> which leads to memory duplication just to get the data serialized
in
> another form. Plus the user *must* use the same graph definition
for
> both `copy` and `merge` or else data loss are going to happen. I
find
> the programming model quite error prone and dangerous.
>
> Emmanuel
>
> On Mon 2012-12-17 9:40, Gordon Yorke wrote:
> > Hello Emmanuel,
> > The goal of a copy graph is to produce a simple subgraph copy of
> > the entity graph for environments where enhancement/proxies may
not
> > be available or where these "guards" can not be retained when
then
> > graph is serialized. The developer has a template in the form of
> > the entity graph which provides the details of which attributes
have
> > legitimate values and which ones should be ignored and this
template
> > is highly recommended for the merge. There is no requirement for
> > "guards" embedded within the copies. In client/server
environments
> > where "guards" would be available there is no need for copy() at
all
> > as the same functionality is achieved serializing entities
loaded
> > with a fetch graph.
> >
> > --Gordon
> > On 17/12/2012 5:25 AM, Emmanuel Bernard wrote:
> > >>>## Use cases
> > >>>
> > >>>I would really like to get use cases associated to each of
the new
> > >>>features proposed here.
> > >>>
> > >>>In particular:
> > >>>- it's unclear to me why you really need loadgraph and
fetchgraph.
> > >>>- why is merge( fetchgraph ) required when you can achieve
the same with
> > >>> - find( fetchgraph )
> > >>> - detach / serialize or whatever
> > >>> - merge() regular method
> > >>merge(EntityGraph) applies when the user is using copy
(EntityGraph)
> > >>to detach an entity tree for serialization. If an attribute is
not
> > >>present in the copy then it must not be merged. So, your
example
> > >>becomes:
> > >> - find (EntityGraph eg1)
> > >> - copy(EntityGraph eg1)
> > >> - serialize out/in
> > >> - merge(EntityGraph eg1)
> > >Sure but the graph returned by copy does contain guards on
uninitialized
> > >properties and associations right? Ie when a non copied
property /
> > >association is traversed, some exception is raised.
> > >
> > >If that's not the case then what are you returning? null or the
> > >primitive default values? I would be strongly against that.
> > >
> > >So assuming the engine has those guards on uninitialized
properties and
> > >associations, then the merge with an EntityGraph is not
necessary as
> > >this information can be discovered (like we do for a regular
merge).
> > >
> > >Emmanuel
> >
>
>
(image/gif attachment: graycol.gif)