On 6/18/05, Andrus Adamchik <andru..bjectstyle.org> wrote:
> This should work. I often use "peer" DataContexts as a workaround too.
>
> > The big difference so far is that a commit would go to the database
> > and not to the parent DataContext. However, I think even that could be
> > easily addressed with some cleverness, by registering the changed
> > objects with the parent DataContext and then discarding the child
> > DataContext.
>
> That would be an implementation of the nested DataContext feature ;-)
>
I was playing around with it and it doesn't seem too difficult to do..
seems like if we do the following to DataContext on commit:
if (getParent() instanceof DataContext) {
mergeWithParent()
} else {
// normal commit
}
mergeWithParent would first perform validateUncommittedObjects(), then
proceed to re-register new/modified objects with the parent context.
That should prevent any
Discarding the DataContext needs addressed though... I didn't consider
this a total implementation of a nested context because I would think
its necessary to ensure the nested context actually can be gc'd when
its done, and of course that the object graph is in a consistent
state. This could be achieved by either killing all of the objects in
the ObjectStore or re-registering the committed objects with the
parent ObjectStore.
If just unregistering the objects of the child context is all that is
required, this shouldn't be a big deal and I'd be happy to work on it
if its not in conflict with the multi-tiered DataContext work, etc
Cris
This archive was generated by hypermail 2.0.0 : Sat Jun 18 2005 - 13:58:10 EDT