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
This archive was generated by hypermail 2.0.0 : Tue Nov 11 2008 - 06:20:06 EST