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
