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.