Thanks for your answer
>
> 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()?
I guess that should be same as with DataContext - normal commit to database.
Upper level is DB after all.
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.
Are you suggesting developers to keep same validation on client & server in
this case? Well, this means that we prefer first solution - to do nothing
:-) Actually I can think of situations when special server validation is
needed - e.g. when it takes long time and will be much longer via ROP.
Still, I agree and think we should leave this as 'known limitation'.
In fact, beside this problem, I've already implemented nested contexts and
hopefully will commit after M5 is released.
Cheers,
Andrey
This archive was generated by hypermail 2.0.0 : Tue Nov 11 2008 - 07:12:54 EST