db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andy Jefferson <a...@jpox.org>
Subject RE: serialize Detachable instance for storage
Date Fri, 24 Mar 2006 19:51:05 GMT
Hi,

> I now understand your issue.  If you declare a PC class that is detachable
> to also be serialized in another class, how do you prevent the detachment
> algorithm from running when the instance is being serialized/deserialized
> for the purposes of persistent storage versus being serialized/deserialized
> for any other reason?  After all, the desired behavior, I think, is to store
> embedded serialized instances as they are in their current state, not in a
> detached-clean or detached-dirty state.

Agreed. Storage in a datastore and retrieval from the datastore should be
transparent to the user, and should not involve detachment.

> // Q1:  During storage, 'address' will be serialized, due to metadata requirement
> and serialized objects are implicitly detached according to spec section 12.6.8.
> Is the address stored in the database detached?

I say no.

> // Q2:  Does 'address' reference a detached instance now because of 
> serialization of Person.address?

I say no.

> Does that mean then, that an Address deserialized from the data store is
> detached-clean or persistent-clean?

persistent-clean. If the user updates a field on a serialised PC object, whilst
within the txn, they would expect it to make it into the datastore. If the object
is detached it has no StateManager and so any change will not be persisted.


The implementation can easily detect when it is serialising an object for storage
in the datastore (as opposed to any normal call to StateManager.preSerialize()),
and JPOX CVS currently assumes that the storage of serialised PC's does *not*
contain the detach state.

PS. There are no TCK tests that check on this currently, as noticed when we had
implemented it in a pure JDO2 spec way, detaching all serialised objects. JPOX
does however have its own unit tests that do check this situation.

--
Andy

Mime
View raw message