cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrus Adamchik <>
Subject Re: Default/Initial values && post validation delegates etc
Date Wed, 06 Sep 2006 07:46:27 GMT

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...
> ... 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 
ObjectContext context = new CayenneContext(decoratedChannel);

Example decorator (missing event support):

public class DataChannelDecorator implements DataChannel {

	protected DataChannel channel;

	public DataChannelDecorator(DataChannel 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);


View raw message