Hi Pinaki,
On 12/18/2012 3:03 PM, Pinaki Poddar wrote:
> > 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.
>
I'm afraid I'm not following you -- doesn't that also create a copy?
regards,
-Linda
> Regards --
>
> Pinaki Poddar
> Chair, Apache OpenJPA Project http://openjpa.apache.org/
> JPA Expert Group Member
> Application & Integration Middleware
>
>
>
>
>
>
> Inactive hide details for Linda DeMichiel ---12/18/2012 02:37:28 PM---On 12/18/2012 2:00 PM, Pinaki Poddar wrote: >
> Gordon,Linda DeMichiel ---12/18/2012 02:37:28 PM---On 12/18/2012 2:00 PM, Pinaki Poddar wrote: > Gordon,
>
> 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
> > >
> >
> >
>
>