Mailing-List: contact jdo-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jdo-dev@db.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Reply-To: <matthew.adams@xcalia.com>
From: "Matthew T. Adams" <matthew.adams@xcalia.com>
To: <jdo-dev@db.apache.org>,
	"'JDO Expert Group'" <jdo-experts-ext@sun.com>
Cc: "Craig Russell" <craig.russell@sun.com>
Date: Fri, 24 Mar 2006 10:51:42 -0800
Organization: Xcalia
Message-ID: <001a01c64f74$145abf50$1e0010ac@DELLZILLA>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <1143139648.4422ed4069919@webmail.jpox.org>
Importance: Normal
Subject: RE: serialize Detachable instance for storage

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:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D
// Class foo.Person
package foo;

public class Person {
    protected Address address;
    // other fields...
}
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D
// Class foo.Address
package foo;

public class Address {
    // fields...
}
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D
<!-- metadata file foo/package.jdo -->
<jdo>
    <package name=3D"foo">
        <class name=3D"Person" detachable=3D"true">
            <field name=3D"Address" serialized=3D"true"/> <!-- note =
serialized
attribute here -->
        </class>
        <class name=3D"Address" detachable=3D"true"> <!-- note =
detachable
attribute here -->
        </class>
    </package>
</jdo>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D
// Some client code
    public void testPersistNewSerializedAddressInstance() {

        PersistenceManagerFactory pmf =3D
JDOHelper.getPersistenceManagerFactory("pmf.properties");
        pmf.setDetachAllOnCommit(true);

        PersistenceManager pm =3D pmf.getPersistenceManager();
        pm.currentTransaction().begin();

        Person person =3D new Person();
        pm.makePersistent(person);

        Address address =3D 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 =3D=3D address' return true?
    }
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D

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:erik@jpox.org]=20
>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=20
>serialized=3D"true"
>}
>
>When you store an instance of A with a ref to B, B is=20
>serialized with detached
>flags, but there is no utility of adding detached flags during=20
>serialization of
>B because its purpose is to store in the database.  So IMO, we=20
>should not add
>detached flags in serialized stored instances.
>
>So, it is a waste of space in the database.
>