You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cayenne.apache.org by Lachlan Deck <la...@ish.com.au> on 2006/09/05 10:18:41 UTC
Default/Initial values && post validation delegates etc
Hi all,
I've got two questions
1) Are initial values set with server code propagated to clients when
an object is created on the client?
The following url...
http://cwiki.apache.org/confluence/display/CAY/Setting+Initial+Values
... suggests using "public void setPersistenceState(int)" for setting
initial values when state is NEW. I assume this is the equivalent of
EOFs awakeFromInsertion(EOEditingContext).
The above method is not triggered on the client (i.e., it's never
called) - so my question is whether (in having this code on the
server) these values will be available initially to the client
context or not?
2) Object modifications
DataContext has event subjects DID_COMMIT, DID_ROLLBACK, WILL_COMMIT
subjects. Great. Where might I find what objects are available via
these notifications?
EOF's delegate has editingContextWillSaveChanges(EOEditingContext)
where if you throw an exception it will abort the save for the
context. How might a listener of the WILL_COMMIT changes event
achieve this? Note: this is not a question about validateForSave.
More importantly - what's the best mechanism to (post validation but
pre actual commit) of actually making some final adjustments to an
object. e.g., something simple such as dateModified field. I know we
could put this into validateForSave but we call this many times prior
to saving on the server - actually whenever someone makes a change in
the gui (in order to highlight what might prevent saving the object).
setPersistentState seems to be only called one time if the state of
an object changes. Would the best way of keeping things like
dateModified and other calculated fields up to date be to overload
writeProperty?
Much appreciated. Thanks.
with regards,
--
Lachlan Deck
lachlan@ish.com.au
Re: Default/Initial values && post validation delegates etc
Posted by Lachlan Deck <la...@ish.com.au>.
Hi Andrus,
On 06/09/2006, at 5:46 PM, Andrus Adamchik wrote:
> Custom values set on the server during commit are not passed back
> to the client (except for the PK). It would be nice if they where,
> so that's something we may consider doing in 3.0.
>
Yes please.
But we're not talking about commit are we? I was talking about
init... what happens when creating a new object on the client? Do any
initial values set on the server get propagated back?
> However 'setPersistenceState' is called on the client when an
> object is created. Not sure why you are not seeing it.
>
I'll check again. Thanks.
>> 2) Object modifications
>>
>> DataContext has event subjects DID_COMMIT, DID_ROLLBACK,
>> WILL_COMMIT subjects. Great. Where might I find what objects are
>> available via these notifications?
>> EOF's delegate has editingContextWillSaveChanges(EOEditingContext)
>> where if you throw an exception it will abort the save for the
>> context. How might a listener of the WILL_COMMIT changes event
>> achieve this? Note: this is not a question about validateForSave.
>>
>
> DataContextTransactionEventListener and
> DataObjectTransactionEventListener are the listener interfaces for
> those events. They can abort the commit. Not sure in what form
> those will be preserved in 3.0 yet. Also these events are only
> available on the server.
>
How might they abort the commit? By simply throwing an exception?
>> More importantly - what's the best mechanism to (post validation
>> but pre actual commit) of actually making some final adjustments
>> to an object. e.g., something simple such as dateModified field. I
>> know we could put this into validateForSave but we call this many
>> times prior to saving on the server - actually whenever someone
>> makes a change in the gui (in order to highlight what might
>> prevent saving the object).
>>
>
> One other very promising technique is decorating a DataChannel with
> an interceptor.
>
> Disclaimer: this hasn't been tested yet, but the facilities are
> there since 1.2. On the server it will work like 90% (and break in
> any method that relies on DataContext.getParentDataDomain()).
> However I think it should work on the client.
>
<...>
Thanks for the info. Shall look into that...
with regards,
--
Lachlan Deck
Re: Default/Initial values && post validation delegates etc
Posted by Andrus Adamchik <an...@objectstyle.org>.
Hi Lachlan,
On Sep 11, 2006, at 10:08 PM, Lachlan Deck wrote:
> Okay - that's good to know.
>
> After looking at the source for CayenneContext.newObject (and non-
> public CayenneContext.createNewObject) it seems to me that
> overriding setPersistentState (as suggested: http://
> cwiki.apache.org/confluence/display/CAY/Setting+Initial+Values) is
> a bad idea, esp for new objects. i.e., at the point of being NEW
> the object's ValueHolder vars have not yet been initiated, it
> doesn't yet have a handle on the context, it's global id has not
> been set, and it's not been registered with the graph manager etc.
> Simply put, bad stuff happens when messing with the objects
> ValueHolder vars prior to all of this.
Hmm... This information on Wiki was posted in pre-remote-object-
persistence days, referring to DataContext. Comparing the code with
the same method in DataContext, the order of initialization is
different between DataContext and CayenneContext. I'd say this is a
bug in Cayenne - let's log it in Jira.
> Last effort question is: does the following call within
> createNewObject(ObjectId) create some sort of event that might
> provide a hook-in point for when the object has been properly
> created and inserted into a context? "graphManager.nodeCreated
> (object.getObjectId());"
no, but aside from my comment above, you can always subclass a context.
Andrus
Re: Default/Initial values && post validation delegates etc
Posted by Andrus Adamchik <an...@objectstyle.org>.
On Sep 12, 2006, at 10:34 AM, Aristedes Maniatis wrote:
>
> Won't JPA require that Cayenne move to the 1.5 JDK to use
> annotations? Will that be a requirement of Cayenne 3.0?
No it won't - current Cayenne APi will work under JDK 1.4. There will
be a number of add-ons that will require JDK 1.5. BTW, theoretically
even JPA can be done with 1.4, as XML descriptors can be used as
alternative to annotations (but we won't be supporting the full JPA
provider under JDK 1.4).
> To be honest I'm a little confused about the relationships between
> 1.2.x, 2.0 and 3.0. Is there a feature list/road map which defines
> what 3.0 will look like and what it will be striving to achieve?
Building it now... JPA is the big thing, the rest will come along.
The fact that we committed to JPA has changed lots of plans... and I
think it will drive lots of the big decisions from now on.
http://cwiki.apache.org/CAY/release-30.html
> Will there be 2.0.1, 2.0.2, etc to match each of 1.2.1, 1.2.2, etc
> but with the changed package names? Or is 2.0 a dead branch now?
We planed to make it a dead branch, but so far applying all patches
between 1.2 and 2.0 has been very easy... So we keep them in sync.
> Since the pain of moving from 1.2 to 2.0 should be trivial for most
> people, is it worth abandoning 1.2.x completely and having just one
> stable branch?
I'd say we should actively work on graduation from Apache incubator
and hold this decision until then. At this point our hands are tied
due to the ASF incubator release requirements, so we have to keep 1.2
bugfix branch.
Andrus
Re: Re: Default/Initial values && post validation delegates etc
Posted by Michael Gentry <bl...@gmail.com>.
At the bottom of http://cwiki.apache.org/CAY/ is "Making Sense of
Release Numbers". 2.0 is supposed to track 1.2 and be a stable
release, but with the apache namespace instead of the objectstyle
namespace. 1.2/2.0 will continue to have bug fixes incorporated in
them, so they aren't really dead. 3.0 is where the new development is
occurring. When 2.0.x is released (there are a few CLA issues slowing
it down), I'd suggest using it if you won't be caused too much
heartburn by the package name changes. However, there is no real
reason to switch to 2.0 if you already have an investment in 1.2 and
are happy with it. Did that help?
/dev/mrg
On 9/12/06, Aristedes Maniatis <ar...@ish.com.au> wrote:
>
> On 12/09/2006, at 11:45 PM, Andrus Adamchik wrote:
>
> > On Sep 11, 2006, at 10:08 PM, Lachlan Deck wrote:
> >
> >> If not - maybe I can put a vote in for a delegate method being
> >> added which is called just prior to the object return. ala
> >> awakeFromInsertion(ObjectContext) :-)
> >
> > BTW, JPA spec [1] defines a bunch of callback annotations
> > (PrePersist, PostPersist, PreRemove, PostRemove, PreUpdate,
> > PostUpdate, PostLoad). We need to think of a way to bring them to
> > Cayenne proper even if it doesn't operate in the "JPA mode".
> >
> > Andrus
> >
> > [1] http://jcp.org/en/jsr/detail?id=220
> >
>
>
> Won't JPA require that Cayenne move to the 1.5 JDK to use
> annotations? Will that be a requirement of Cayenne 3.0?
>
> To be honest I'm a little confused about the relationships between
> 1.2.x, 2.0 and 3.0. Is there a feature list/road map which defines
> what 3.0 will look like and what it will be striving to achieve? Will
> there be 2.0.1, 2.0.2, etc to match each of 1.2.1, 1.2.2, etc but
> with the changed package names? Or is 2.0 a dead branch now?
>
> Since the pain of moving from 1.2 to 2.0 should be trivial for most
> people, is it worth abandoning 1.2.x completely and having just one
> stable branch?
>
>
> 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: Default/Initial values && post validation delegates etc
Posted by Aristedes Maniatis <ar...@ish.com.au>.
On 12/09/2006, at 11:45 PM, Andrus Adamchik wrote:
> On Sep 11, 2006, at 10:08 PM, Lachlan Deck wrote:
>
>> If not - maybe I can put a vote in for a delegate method being
>> added which is called just prior to the object return. ala
>> awakeFromInsertion(ObjectContext) :-)
>
> BTW, JPA spec [1] defines a bunch of callback annotations
> (PrePersist, PostPersist, PreRemove, PostRemove, PreUpdate,
> PostUpdate, PostLoad). We need to think of a way to bring them to
> Cayenne proper even if it doesn't operate in the "JPA mode".
>
> Andrus
>
> [1] http://jcp.org/en/jsr/detail?id=220
>
Won't JPA require that Cayenne move to the 1.5 JDK to use
annotations? Will that be a requirement of Cayenne 3.0?
To be honest I'm a little confused about the relationships between
1.2.x, 2.0 and 3.0. Is there a feature list/road map which defines
what 3.0 will look like and what it will be striving to achieve? Will
there be 2.0.1, 2.0.2, etc to match each of 1.2.1, 1.2.2, etc but
with the changed package names? Or is 2.0 a dead branch now?
Since the pain of moving from 1.2 to 2.0 should be trivial for most
people, is it worth abandoning 1.2.x completely and having just one
stable branch?
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: Default/Initial values && post validation delegates etc
Posted by Andrus Adamchik <an...@objectstyle.org>.
On Sep 11, 2006, at 10:08 PM, Lachlan Deck wrote:
> If not - maybe I can put a vote in for a delegate method being
> added which is called just prior to the object return. ala
> awakeFromInsertion(ObjectContext) :-)
BTW, JPA spec [1] defines a bunch of callback annotations
(PrePersist, PostPersist, PreRemove, PostRemove, PreUpdate,
PostUpdate, PostLoad). We need to think of a way to bring them to
Cayenne proper even if it doesn't operate in the "JPA mode".
Andrus
[1] http://jcp.org/en/jsr/detail?id=220
Re: Default/Initial values && post validation delegates etc
Posted by Lachlan Deck <la...@ish.com.au>.
Hi there,
On 07/09/2006, at 4:22 PM, Andrus Adamchik wrote:
> On Sep 7, 2006, at 7:27 AM, Lachlan Deck wrote:
>
>> On 06/09/2006, at 5:46 PM, Andrus Adamchik wrote:
>>
>>> Custom values set on the server during commit are not passed back
>>> to the client (except for the PK). It would be nice if they
>>> where, so that's something we may consider doing in 3.0.
>>
>> Yes please.
>>
>> But we're not talking about commit are we? I was talking about
>> init... what happens when creating a new object on the client? Do
>> any initial values set on the server get propagated back?
>
> Yes, I am talking commit, since commit is the first time when a new
> object created on the client is sent to the server. Until then it
> sits on the client and server has no chance of participating in its
> lifecycle.
>
> What happens on commit is this:
>
> * Client transfers the information about an object as a bunch of
> "diffs".
> * Server instantiates a server-side object from those diffs.
> * Server commits its DataContext.
Okay - that's good to know.
After looking at the source for CayenneContext.newObject (and non-
public CayenneContext.createNewObject) it seems to me that overriding
setPersistentState (as suggested: http://cwiki.apache.org/confluence/
display/CAY/Setting+Initial+Values) is a bad idea, esp for new
objects. i.e., at the point of being NEW the object's ValueHolder
vars have not yet been initiated, it doesn't yet have a handle on the
context, it's global id has not been set, and it's not been
registered with the graph manager etc. Simply put, bad stuff happens
when messing with the objects ValueHolder vars prior to all of this.
Last effort question is: does the following call within
createNewObject(ObjectId) create some sort of event that might
provide a hook-in point for when the object has been properly created
and inserted into a context? "graphManager.nodeCreated
(object.getObjectId());"
If not - maybe I can put a vote in for a delegate method being added
which is called just prior to the object return. ala
awakeFromInsertion(ObjectContext) :-)
with regards,
--
Lachlan Deck
Re: Default/Initial values && post validation delegates etc
Posted by Andrus Adamchik <an...@objectstyle.org>.
On Sep 7, 2006, at 7:27 AM, Lachlan Deck wrote:
> On 06/09/2006, at 5:46 PM, Andrus Adamchik wrote:
>
>> Custom values set on the server during commit are not passed back
>> to the client (except for the PK). It would be nice if they where,
>> so that's something we may consider doing in 3.0.
>
> Yes please.
>
> But we're not talking about commit are we? I was talking about
> init... what happens when creating a new object on the client? Do
> any initial values set on the server get propagated back?
Yes, I am talking commit, since commit is the first time when a new
object created on the client is sent to the server. Until then it
sits on the client and server has no chance of participating in its
lifecycle.
What happens on commit is this:
* Client transfers the information about an object as a bunch of
"diffs".
* Server instantiates a server-side object from those diffs.
* Server commits its DataContext.
>>> 2) Object modifications
>>>
>>> DataContext has event subjects DID_COMMIT, DID_ROLLBACK,
>>> WILL_COMMIT subjects. Great. Where might I find what objects are
>>> available via these notifications?
>>> EOF's delegate has editingContextWillSaveChanges
>>> (EOEditingContext) where if you throw an exception it will abort
>>> the save for the context. How might a listener of the WILL_COMMIT
>>> changes event achieve this? Note: this is not a question about
>>> validateForSave.
>>
>> DataContextTransactionEventListener and
>> DataObjectTransactionEventListener are the listener interfaces for
>> those events. They can abort the commit. Not sure in what form
>> those will be preserved in 3.0 yet. Also these events are only
>> available on the server.
>
> How might they abort the commit? By simply throwing an exception?
Yes, since event dispatch is done synchronously in the same thread.
Still like I said, since we want to consolidate events at the
DataChannel level, you should expect some changes (deprecation and/or
removal) of these listeners. You'll have to switch to
DataChannelListener (once an extra subject that I mentioned becomes
available).
Andrus
Re: Default/Initial values && post validation delegates etc
Posted by Lachlan Deck <la...@gmail.com>.
Hi Andrus,
On 06/09/2006, at 5:46 PM, Andrus Adamchik wrote:
> Custom values set on the server during commit are not passed back
> to the client (except for the PK). It would be nice if they where,
> so that's something we may consider doing in 3.0.
Yes please.
But we're not talking about commit are we? I was talking about
init... what happens when creating a new object on the client? Do any
initial values set on the server get propagated back?
> However 'setPersistenceState' is called on the client when an
> object is created. Not sure why you are not seeing it.
I'll check again. Thanks.
>> 2) Object modifications
>>
>> DataContext has event subjects DID_COMMIT, DID_ROLLBACK,
>> WILL_COMMIT subjects. Great. Where might I find what objects are
>> available via these notifications?
>> EOF's delegate has editingContextWillSaveChanges(EOEditingContext)
>> where if you throw an exception it will abort the save for the
>> context. How might a listener of the WILL_COMMIT changes event
>> achieve this? Note: this is not a question about validateForSave.
>
> DataContextTransactionEventListener and
> DataObjectTransactionEventListener are the listener interfaces for
> those events. They can abort the commit. Not sure in what form
> those will be preserved in 3.0 yet. Also these events are only
> available on the server.
How might they abort the commit? By simply throwing an exception?
>> More importantly - what's the best mechanism to (post validation
>> but pre actual commit) of actually making some final adjustments
>> to an object. e.g., something simple such as dateModified field. I
>> know we could put this into validateForSave but we call this many
>> times prior to saving on the server - actually whenever someone
>> makes a change in the gui (in order to highlight what might
>> prevent saving the object).
>
> One other very promising technique is decorating a DataChannel with
> an interceptor.
>
> Disclaimer: this hasn't been tested yet, but the facilities are
> there since 1.2. On the server it will work like 90% (and break in
> any method that relies on DataContext.getParentDataDomain()).
> However I think it should work on the client.
<...>
Thanks for the info. Shall look into that...
with regards,
--
Lachlan Deck
Re: Default/Initial values && post validation delegates etc
Posted by Andrus Adamchik <an...@objectstyle.org>.
On Sep 5, 2006, at 12:18 PM, Lachlan Deck wrote:
> 1) Are initial values set with server code propagated to clients
> when an object is created on the client?
>
> The following url...
> http://cwiki.apache.org/confluence/display/CAY/Setting+Initial+Values
>
> ... suggests using "public void setPersistenceState(int)" for
> setting initial values when state is NEW. I assume this is the
> equivalent of EOFs awakeFromInsertion(EOEditingContext).
>
> The above method is not triggered on the client (i.e., it's never
> called) - so my question is whether (in having this code on the
> server) these values will be available initially to the client
> context or not?
Custom values set on the server during commit are not passed back to
the client (except for the PK). It would be nice if they where, so
that's something we may consider doing in 3.0. However
'setPersistenceState' is called on the client when an object is
created. Not sure why you are not seeing it.
> 2) Object modifications
>
> DataContext has event subjects DID_COMMIT, DID_ROLLBACK,
> WILL_COMMIT subjects. Great. Where might I find what objects are
> available via these notifications?
> EOF's delegate has editingContextWillSaveChanges(EOEditingContext)
> where if you throw an exception it will abort the save for the
> context. How might a listener of the WILL_COMMIT changes event
> achieve this? Note: this is not a question about validateForSave.
DataContextTransactionEventListener and
DataObjectTransactionEventListener are the listener interfaces for
those events. They can abort the commit. Not sure in what form those
will be preserved in 3.0 yet. Also these events are only available on
the server.
I wonder if we should instead add another pre-commit subject to the
DataChannel events that are here to stay and work the same way on the
client and on the server?? This may be the simplest solution...
> More importantly - what's the best mechanism to (post validation
> but pre actual commit) of actually making some final adjustments to
> an object. e.g., something simple such as dateModified field. I
> know we could put this into validateForSave but we call this many
> times prior to saving on the server - actually whenever someone
> makes a change in the gui (in order to highlight what might prevent
> saving the object).
One other very promising technique is decorating a DataChannel with
an interceptor.
Disclaimer: this hasn't been tested yet, but the facilities are there
since 1.2. On the server it will work like 90% (and break in any
method that relies on DataContext.getParentDataDomain()). However I
think it should work on the client.
Example of context creation on the client:
ClientChannel channel = ...
DataChannelDecorator decoratedChannel = new DataChannelDecorator
(channel);
ObjectContext context = new CayenneContext(decoratedChannel);
Example decorator (missing event support):
public class DataChannelDecorator implements DataChannel {
protected DataChannel channel;
public DataChannelDecorator(DataChannel channel) {
this.channel = channel;
}
public EntityResolver getEntityResolver() {
return channel.getEntityResolver();
}
public EventManager getEventManager() {
return channel.getEventManager();
}
public QueryResponse onQuery(ObjectContext originatingContext, Query
query) {
return channel.onQuery(originatingContext, query);
}
public GraphDiff onSync(ObjectContext originatingContext,
GraphDiff changes, int syncType) {
System.out.println("**** Sync in progress");
return channel.onSync(originatingContext, changes, syncType);
}
}
Andrus