On Oct 16, 2007, at 2:57 PM, Kevin Menard wrote:
> The problem with localObject is that it does not traverse the whole
> graph,
> making it practically useless in all but the most trivial situations.
That fact is *almost* transparent as relationships of the local
object are expanded as needed. What it doesn't cover is modified
objects in the graph. This is where we could use a method like JPA
'merge' that would traverse already inflated graph and clone all
local changes for objects attached to a given object into the target
context.
> Manually copying over the graph is doable, but a lot of work for
> something
> that really should be far easier.
>
> For example, we have customers and orders. All orders are
> associated with
> customers. We keep the customer info and order info in two different
> contexts for the most part, because we don't want to prematurely
> commit an
> order while a customer may feel it necessary to change his shipping
> address,
> for example.
>
> What we've resorted to doing is committing the customer data, then
> doing a
> requery based on the ObjectID using the order context. This allows
> us to
> get a fully populated object. Of course, this means more trips to
> the DB ...
Not at all. All contexts work off of the same DataDomain cache, so
lookup by ObjectId is fairly efficient. But it is not transparent, I
agree.
> I suppose the problem is exacerbated by the null context problem.
> If we fix that, we'd likely be in much better shape.
So it seems to me it comes down to implementing JPA-compatible
"persist" and "merge" concepts on top of what we already have.
Andrus
This archive was generated by hypermail 2.0.0 : Tue Oct 16 2007 - 08:13:24 EDT