>
>
> Would committing a nested context on the client cause a connection to be
> made to the server and lifecycle events, validation run on the server for
> objects in that context? If so, will changes which are made by lifecycle
> events (eg. new objects created) be propagated to the client (which
> currently doesn't happen) so they can be included in the parent context when
> it is then committed?
>
> Or do they remain purely on the client until the parent context is
> committed? In that case, what happens if the server validation fails for
> objects in the child context?
Nested context idea specifies that changes should be purely on the client.
Otherwise we lose ability to commitChangesToParent()
Client nested context is normal CayContext, just with another DataChannel,
(i.e. source to commit changes to). So validation works *on client* within
context which called commitChanges(). Changes to server (with server
validation & lifecycles) will proceed through all context hierarchy if you
call CayenneContext.commitChanges(),
not CayenneContext.commitChangesToParent(). That's just the same as with
DataContext, I haven't invented anything new.
As you correctly pointed out, problem occurs with the following sequence:
1. Nested CayContext [with incorrect changes] is committed to parent.
Validation on nested client context succeeds
2. Parent context is committed to server. Validation on client context
succeeds since it did in #1
3. Server validation fails. Parent context changes are rolled back.
By default in nested context they do not.
Right now I cannot think of ideal solution.
At the minimum we could just do nothing and hope that server validation will
succeed if client did.
We could check objects before committing to parent (i.e. do 'false' commit
to server), but I'm afraid that'll be too expensive.
Or we could send notification to children if parent commit failed, but this
is quite unnatural to make changes in child context behind the scenes.
Would be great if we together thought about it
Andrey
This archive was generated by hypermail 2.0.0 : Fri Oct 24 2008 - 05:03:15 EDT