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