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
