Hi Erik, 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. Here is an example that I think illustrates the issue:
========================================================== // Class foo.Person package foo; public class Person { protected Address address; // other fields... } ========================================================== // Class foo.Address package foo; public class Address { // fields... } ========================================================== <!-- metadata file foo/package.jdo --> <jdo> <package name="foo"> <class name="Person" detachable="true"> <field name="Address" serialized="true"/> <!-- note serialized attribute here --> </class> <class name="Address" detachable="true"> <!-- note detachable attribute here --> </class> </package> </jdo> ========================================================== // Some client code public void testPersistNewSerializedAddressInstance() { PersistenceManagerFactory pmf = JDOHelper.getPersistenceManagerFactory("pmf.properties"); pmf.setDetachAllOnCommit(true); PersistenceManager pm = pmf.getPersistenceManager(); pm.currentTransaction().begin(); Person person = new Person(); pm.makePersistent(person); Address address = new Address(); person.setAddress(address); pm.currentTransaction().commit(); // 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? In // other words, does the serialized form of the Address instance stored in the database contain detachment // information? // Q2: Does 'address' reference a detached instance now because of serialization of Person.address? // Q3: Does 'person.address == address' return true? } ========================================================== There are other scenarios that should probably be clarified as well, in particular, when an Address is loaded from the data store, it is deserialized. According to the spec, deserialized detached instances are in one of the detached states (detached-clean, detached-dirty). Does that mean, then, that an Address deserialized from the data store is detached-clean or persistent-clean? --matthew >-----Original Message----- >From: Erik Bengtson [mailto:[EMAIL PROTECTED] >Sent: Thursday, March 23, 2006 10:47 AM >To: JDO Expert Group; Apache JDO project >Subject: Re: serialize Detachable instance for storage > > >Hi Craig, > >> On Mar 17, 2006, at 11:40 AM, Erik Bengtson wrote: >> >> > Hi, >> > >> > If we serialize a detachable instance for storage, does it have the >> > detach state >> > populated? >> >> Yes. Regardless of whether it's currently managed or already >> detached, the detached state is part of the serialized state of the >> instance. >> >> > It is at least a waste of space. >> >> I don't understand how the detached state is wasted space. It >> contains information that's needed if the instance is in future >> attached to a persistence manager. >> > >Let me ask differently: say a class A { B b; // detachable and >serialized="true" >} > >When you store an instance of A with a ref to B, B is >serialized with detached >flags, but there is no utility of adding detached flags during >serialization of >B because its purpose is to store in the database. So IMO, we >should not add >detached flags in serialized stored instances. > >So, it is a waste of space in the database. >