You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cayenne.apache.org by Kevin Menard <km...@servprise.com> on 2008/02/26 18:38:43 UTC
ROP listener semantics
Forgive the simplistic nature of this question, but I want to verify my
understanding of listeners.
If a server entity has a pre-persist listener and the corresponding
client entity does as well, then both listeners will be executed, with
the server called first? Moreover, any modifications made at the server
level will be reflected back in the client?
The simple case at hand is to update a date creation field. I have to
have this listener in the server because objects can be created over
there. I thought I needed to duplicate this logic for the client as
well, but after stepping through the debugger, I don't think I have to.
Thanks,
Kevin
--
Kevin Menard
Servprise International, Inc.
Remote reboot & power control for your network
www.servprise.com +1 508.892.3823 x308
Re: ROP listener semantics
Posted by Aristedes Maniatis <ar...@ish.com.au>.
On 27/02/2008, at 5:20 AM, Andrus Adamchik wrote:
> This is actually a separate issue from callbacks/listeners. And we
> need to fix it .. badly... The object diff exchange protocol
> supports sending server-side changes back to the client (and in fact
> we are using that - for generated primary keys), but we also need to
> capture and send back the changes that happened to objects as a
> result of callbacks. IMO this is a major task that we'd rather do
> sooner than later.
This would be very useful. Right now we have quite a lot of code which
sets objects to hollow after commit, in order to get fresh copies of
the data from the server with callback changes included. But it is
easy to make a mistake and forget.
Ari Maniatis
-------------------------->
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: ROP listener semantics
Posted by Andrus Adamchik <an...@objectstyle.org>.
On Feb 26, 2008, at 8:20 PM, Andrus Adamchik wrote:
>> Moreover, any modifications made at the server
>> level will be reflected back in the client?
>
> This is actually a separate issue from callbacks/listeners. And we
> need to fix it .. badly... The object diff exchange protocol
> supports sending server-side changes back to the client (and in fact
> we are using that - for generated primary keys), but we also need to
> capture and send back the changes that happened to objects as a
> result of callbacks. IMO this is a major task that we'd rather do
> sooner than later.
I just implemented this on SVN trunk per CAY-789. I'd appreciate if
somebody could test it in production and report how it works. To make
things easier for those not setup to build Cayenne, here are the fresh
server and client binaries:
http://people.apache.org/~aadamchik/nightly/03012008/
Andrus
Re: ROP listener semantics
Posted by Andrus Adamchik <an...@objectstyle.org>.
On Feb 26, 2008, at 8:42 PM, Kevin Menard wrote:
> This is a bit surprising to me, because I think that they do work.
> For
> my server class hierarchy I have one base class that I've made
> implement
> LifecycleListener. I've done the same for the client classes. In the
> modeler, I mapped each of these classes as listeners at the DataMap
> level. I couldn't get it to just acknowledge that these were
> listeners
> based on the interface, so I mapped the pre-persist methods for each.
>
> I then fired up the server in a debugger and a client in the debugger.
> Accessing a simple CRUD page in the client, both pre-persist methods
> were entered: the base server class one and the base client class one.
Let me investigate. This may have leaked somehow beyond the first tier
DataContext...
Andrus
RE: ROP listener semantics
Posted by Kevin Menard <km...@servprise.com>.
> -----Original Message-----
> From: Andrus Adamchik [mailto:andrus@objectstyle.org]
> Sent: Tuesday, February 26, 2008 1:20 PM
> To: user@cayenne.apache.org
> Subject: Re: ROP listener semantics
>
> Per my other reply to a similar question, there are no callbacks or
> listeners on the client at all (and for that matter they do not work
> with nested contexts either - only the topmost parent context's object
> events will cause mapped callbacks to fire).
This is a bit surprising to me, because I think that they do work. For
my server class hierarchy I have one base class that I've made implement
LifecycleListener. I've done the same for the client classes. In the
modeler, I mapped each of these classes as listeners at the DataMap
level. I couldn't get it to just acknowledge that these were listeners
based on the interface, so I mapped the pre-persist methods for each.
I then fired up the server in a debugger and a client in the debugger.
Accessing a simple CRUD page in the client, both pre-persist methods
were entered: the base server class one and the base client class one.
> While this is consistent, it is far from user-friendly. The problem is
> not technical (it is easy to invoke callbacks anywhere), but rather a
> design one. My assertion is that callbacks and listeners will likely
> be very different between the layers. In your example for instance, it
> wouldn't make sense to set the 'creation_date' via a callback twice.
> This in turn presents a challenge in mapping callbacks in the modeler.
> This task is hard as is (I just tried to remap my manual callbacks
> using M3 Modeler... not easy at all ... we may need alternative UI for
> that task). If we'd have to map two separate sets of callbacks, client
> and server, things will get even messier.
Perhaps what I'm seeing is environment related then.
I think if the semantics of execution order are well-defined, it's not
as big a problem. If I can be assured that the server will execute and
the changes will end up reflected in the client, then that's good enough
for me. I can then use the client listeners for executing stuff that
really only belongs to the client.
I do agree that mapping two different sets of callbacks is going to be
messy. I'd probably keep the same UI but have a checkbox or something
for client versus server. Where it will likely start getting tricky is
when we can finally use a single class hierarchy for server & client.
> As a quick fix I was thinking of enabling manual callbacks and
> listeners on the ROP client, but still avoid exposing server callbacks
> on the client.
Agreed. But, I'd like to avoid anything that makes unification of
server & client hierarchy a harder task than it already is.
> > Moreover, any modifications made at the server
> > level will be reflected back in the client?
>
> This is actually a separate issue from callbacks/listeners. And we
> need to fix it .. badly... The object diff exchange protocol supports
> sending server-side changes back to the client (and in fact we are
> using that - for generated primary keys), but we also need to capture
> and send back the changes that happened to objects as a result of
> callbacks. IMO this is a major task that we'd rather do sooner than
> later.
Gotcha. In this example, it looked as if the changes were sent back. I
haven't looked into enough to see if I just did a refresh query
somewhere along the way though.
We can take the rest of the discussion to the dev list I guess.
--
Kevin
Re: ROP listener semantics
Posted by Andrus Adamchik <an...@objectstyle.org>.
Per my other reply to a similar question, there are no callbacks or
listeners on the client at all (and for that matter they do not work
with nested contexts either - only the topmost parent context's object
events will cause mapped callbacks to fire).
While this is consistent, it is far from user-friendly. The problem is
not technical (it is easy to invoke callbacks anywhere), but rather a
design one. My assertion is that callbacks and listeners will likely
be very different between the layers. In your example for instance, it
wouldn't make sense to set the 'creation_date' via a callback twice.
This in turn presents a challenge in mapping callbacks in the modeler.
This task is hard as is (I just tried to remap my manual callbacks
using M3 Modeler... not easy at all ... we may need alternative UI for
that task). If we'd have to map two separate sets of callbacks, client
and server, things will get even messier.
As a quick fix I was thinking of enabling manual callbacks and
listeners on the ROP client, but still avoid exposing server callbacks
on the client.
> Moreover, any modifications made at the server
> level will be reflected back in the client?
This is actually a separate issue from callbacks/listeners. And we
need to fix it .. badly... The object diff exchange protocol supports
sending server-side changes back to the client (and in fact we are
using that - for generated primary keys), but we also need to capture
and send back the changes that happened to objects as a result of
callbacks. IMO this is a major task that we'd rather do sooner than
later.
Thanks,
Andrus
On Feb 26, 2008, at 7:38 PM, Kevin Menard wrote:
> Forgive the simplistic nature of this question, but I want to verify
> my
> understanding of listeners.
>
> If a server entity has a pre-persist listener and the corresponding
> client entity does as well, then both listeners will be executed, with
> the server called first? Moreover, any modifications made at the
> server
> level will be reflected back in the client?
>
> The simple case at hand is to update a date creation field. I have to
> have this listener in the server because objects can be created over
> there. I thought I needed to duplicate this logic for the client as
> well, but after stepping through the debugger, I don't think I have
> to.
>
> Thanks,
> Kevin
>
> --
> Kevin Menard
> Servprise International, Inc.
> Remote reboot & power control for your network
> www.servprise.com +1 508.892.3823 x308
>
>
>