On 24/10/2008, at 8:02 PM, Andrey Razumovsky wrote:
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.
Indeed.
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().
What would the behaviour be for a non-nested context on client calling
commitChangesToParent()?
That's just the same as with
DataContext, I haven't invented anything new.
sure.
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
That seems normal. I mean currently during commit validation is only
run on the server assuming success on client (where the server is like
the parent). So it'll be the responsibility of the programmer to
handle this.
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.
Yeah - that's fragile.
We could check objects before committing to parent (i.e. do 'false'
commit
to server), but I'm afraid that'll be too expensive.
Don't see this is necessary besides being expensive. This would be
better served by allowing server/client classes to utilise a business
logic shared static helper that can be shared between the server/
client classes to perform validation against.
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
with regards,
--
Lachlan Deck
