Lazy loading support is optional. In an environment where enhancement
is not available all attributes except for XToMany and
ElementCollections will be loaded so there is no unloaded attributes for
these relationships and nothing for merge to get wrong. In other words
there is no "remembering" when there is no enhancement and the spec is
written to handle that.
> I have explained that passing the graph to a serialization or traversal
> framework is not one of those use case as we have demonstrated with Bean
> Validation.
It is not the serialization framework that is the concern. Any EE
framework could be updated to support the already existing JPA
isLoaded(). It is when the client is not EE that the guards/markers are
lost and there is no way to determine the difference between unloaded
data and the client having set the attribute to null. With a template
the user indicates what attributes should be ignored because they were
not loaded before.
--Gordon
On 19/12/2012 1:28 PM, Emmanuel Bernard wrote:
> On Tue 2012-12-18 17:02, Gordon Yorke wrote:
>> There is no requirement for a user to use copy(), the specification
>> already has support for partial loading of entities and providers
>> are currently required to support serialization so there are no
>> barriers for a user to serialize a tree of entities and only the
>> loaded data would be expected to be serialized. The only purpose of
>> copy() is to allow users to create a copy of a portion of an entity
>> graph. Many users have asked for this functionality and with
>> EntityGraphs we now have a means to template the operation so why
>> not add the functionality.
>> I see no need for "guards" as users are
>> intentionally creating a truncated entity graph with a template that
>> they have provided. Also, "guards" add unnecessary complexity and
>> require some sort of enhancement of the entity classes that has not
>> yet and should not be required by the specification.
> Hum. When I load an entity today and serialize / deserialize this
> object graph, then the object graph "remembers" what association has
> been loaded and what has not. Same for properties though these ones
> require indeed bytecode enhancement. If it was not, merge would erase
> lazy associations with null or some other random value.
>
> So we have that feature today. What I am claiming is that we can rely on
> the same mechanisms we have today. The semantic of copy which would
> replace lazy associations with null or null collection - it's not
> defined by the way AFAIR - is really something I am strongly against
> unless we have a very valid use case in front of us.
>
> I have explained that passing the graph to a serialization or traversal
> framework is not one of those use case as we have demonstrated with Bean
> Validation.
>
> Emmanuel
>
> PS: I'm officially on vacations tonight and till early next year so I
> might not be following this thread too closely in the next few days.
> Happy holidays everyone.