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
> >
>
>