You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cayenne.apache.org by Lachlan Deck <la...@gmail.com> on 2008/11/11 12:19:28 UTC
Re: Nested context on ROP proposal
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
Re: Nested context on ROP proposal
Posted by Andrus Adamchik <an...@objectstyle.org>.
Please go ahead. Trunk is open for new development for a couple of
weeks now.
Cheers,
Andrus
On Dec 8, 2008, at 12:16 PM, Andrey Razumovsky wrote:
> Okay, M5 is now branched, and if noone has objections on API
> changes, I will
> soon commit
>
> 2008/11/11, Aristedes Maniatis <ar...@ish.com.au>:
>>
>>
>> On 11/11/2008, at 11:12 PM, Andrey Razumovsky wrote:
>>
>> 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.
>>>
>>
>> Absolutely we need to be able to keep them separate. Sometimes. But
>> because
>> client and server entity classes aren't in the same inheritance
>> tree, it is
>> really hard to share the 90% of validation code which is identical.
>>
>> In our application, we validate on each keystroke, allowing us to
>> enable/disable the save button and implement nice GUI warnings.
>> Obviously
>> this needs to be really fast on the client. And so there is more
>> validation
>> on the server which does not exist on the client. But we've been
>> bitten
>> sometimes by not keeping the two in sync where they should be.
>>
>>
>> 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.
>>>
>>
>> Terrific! I can definitely say we'll be able to give it a solid
>> workout
>> here.
>>
>>
>> Andrey, you might like to add the special limitations to be aware
>> of on
>> this page and a note about it being available in M6:
>>
>> http://cwiki.apache.org/confluence/display/CAYDOC/Nested+DataContexts
>>
>> I know it is slightly premature, but I'm very excited :-)
>>
>>
>> Ari
>>
>>
>>
>> -------------------------->
>> ish
>> http://www.ish.com.au
>> Level 1, 30 Wilson Street Newtown 2042 Australia
>> phone +61 2 9550 5001 fax +61 2 9550 4001
>> GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
>>
>>
>>
Re: Nested context on ROP proposal
Posted by Andrey Razumovsky <ra...@gmail.com>.
Okay, M5 is now branched, and if noone has objections on API changes, I will
soon commit
2008/11/11, Aristedes Maniatis <ar...@ish.com.au>:
>
>
> On 11/11/2008, at 11:12 PM, Andrey Razumovsky wrote:
>
> 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.
>>
>
> Absolutely we need to be able to keep them separate. Sometimes. But because
> client and server entity classes aren't in the same inheritance tree, it is
> really hard to share the 90% of validation code which is identical.
>
> In our application, we validate on each keystroke, allowing us to
> enable/disable the save button and implement nice GUI warnings. Obviously
> this needs to be really fast on the client. And so there is more validation
> on the server which does not exist on the client. But we've been bitten
> sometimes by not keeping the two in sync where they should be.
>
>
> 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.
>>
>
> Terrific! I can definitely say we'll be able to give it a solid workout
> here.
>
>
> Andrey, you might like to add the special limitations to be aware of on
> this page and a note about it being available in M6:
>
> http://cwiki.apache.org/confluence/display/CAYDOC/Nested+DataContexts
>
> I know it is slightly premature, but I'm very excited :-)
>
>
> Ari
>
>
>
> -------------------------->
> ish
> http://www.ish.com.au
> Level 1, 30 Wilson Street Newtown 2042 Australia
> phone +61 2 9550 5001 fax +61 2 9550 4001
> GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
>
>
>
Re: Nested context on ROP proposal
Posted by Aristedes Maniatis <ar...@ish.com.au>.
On 11/11/2008, at 11:12 PM, Andrey Razumovsky wrote:
> 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.
Absolutely we need to be able to keep them separate. Sometimes. But
because client and server entity classes aren't in the same
inheritance tree, it is really hard to share the 90% of validation
code which is identical.
In our application, we validate on each keystroke, allowing us to
enable/disable the save button and implement nice GUI warnings.
Obviously this needs to be really fast on the client. And so there is
more validation on the server which does not exist on the client. But
we've been bitten sometimes by not keeping the two in sync where they
should be.
> 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.
Terrific! I can definitely say we'll be able to give it a solid
workout here.
Andrey, you might like to add the special limitations to be aware of
on this page and a note about it being available in M6:
http://cwiki.apache.org/confluence/display/CAYDOC/Nested+DataContexts
I know it is slightly premature, but I'm very excited :-)
Ari
-------------------------->
ish
http://www.ish.com.au
Level 1, 30 Wilson Street Newtown 2042 Australia
phone +61 2 9550 5001 fax +61 2 9550 4001
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
Re: Nested context on ROP proposal
Posted by Lachlan Deck <la...@gmail.com>.
On 11/11/2008, at 11:12 PM, Andrey Razumovsky wrote:
> 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
> :-)
Easy ;-)
> 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.
Additionally when for security reasons it only makes sense on the
server.
> 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.
Great.
with regards,
--
Lachlan Deck
Re: Nested context on ROP proposal
Posted by Andrey Razumovsky <ra...@gmail.com>.
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