While we can/should definitely continue to discuss the best way to
achieve this or comparable functionality, I have to second Gordon's
point that the ability to "prune off" part of an entity graph is
something that we have been getting requests for for quite some time.
Fetch graphs and detach alone don't provide this functionality,
insofar as they may result in exposing more data than the application
wishes to expose (particularly since our rules for FetchType.LAZY
allow the implementation to bring in more than has been requested),
thus entailing the need for "manual" pruning.
In any case, I would like to get this functionality out in the Public
Draft for wider exposure (and hopefully wider feedback).
Depending on this results of that, we can decide how best to proceed.
In any event, I plan to add a note to the specification to the effect
that the copy and merge graph options are still under discussion and
require further feedback.
Sound reasonable??
thanks,
-Linda
On 12/18/2012 2:35 PM, Linda DeMichiel wrote:
>
>
> 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
>> >
>>
>>