Yeah, migrating to ObjectContext is now a prerequisite.
Won't comment on the specifics now, but the design direction with
this was to minimize the number of methods in the ObjectContext
interface, so a few DataContext methods didn't make it there. I guess
we need to pull to DataObjectUtils any remaining "derived"
DataContext methods that can be executed on a generic ObjectContext.
Andrus
On Mar 16, 2007, at 2:27 AM, Lachlan Deck wrote:
Hello again,
On 15/03/2007, at 12:15 AM, Andrus Adamchik wrote:
One last try at guessing it. On the server you have to do some
magic to enable callbacks (hopefully eventually this will be more
transparent). See "Enabling Callbacks" chapter at the bottom of
this page:
http://cayenne.apache.org/doc/lifecycle-callbacks.html
if this doesn't help, please file a bug with code samples.
You were right. I'd not read far enough down the page. It is
somewhat convoluted to implement I must say. I'm now subclassing
ObjectContextCallbackInterceptor to add a couple of methods to it
(e.g., like hasChanges() etc from DataContext).
There's one other problem that this now imposes: previously using a
DataContext we could do:
Object someInstance = dc.objectFromDataRow( entityClass,
someDataRow, refreshes );
Would this now be the best solution?
public class ObjectContext extends ObjectContextCallbackInterceptor
{
private DataContext _dataContext;
<...>
public DataObject objectFromDataRow( Class entityClass, DataRow
paymentRow, boolean refresh )
{
DataObject anObject;
anObject = _dataContext.objectFromDataRow( entityClass,
paymentRow, refresh );
if ( anObject != null )
return ( DataObject )localObject( anObject.getObjectId(),
anObject );
return null;
}
}
Otherwise it seems to return an object that seems to be in the
wrong context so far as addToOneRelationship etc is concerned...
Be nice if ObjectContext, DataContext et al were better unified. Or
that DataObjectUtils could return an object for a DataRow to
abstract all this.
with regards,
--
Lachlan Deck
