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
