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>,
	<andy@jpox.org>,
	<jdo-experts-ext@sun.com>
Date: Fri, 24 Mar 2006 12:22:47 -0800
Organization: Xcalia
Message-ID: <001d01c64f80$cd89dbd0$1e0010ac@DELLZILLA>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
In-Reply-To: <20060324193843.D58AF10FB007@asf.osuosl.org>
Importance: Normal
Subject: RE: serialize Detachable instance for storage

I agree on all points, Andy.  Craig, I would think it to be beneficial to
explicitly state something about what compliant implementations should do
when serializing instances for the purposes of embedded storage versus for
any other reason.

It is not currently discussed, although it does seem intutive for the JDO
implementation to handle this situation correctly.

--matthew

>-----Original Message-----
>From: Andy Jefferson [mailto:andy@jpox.org] 
>Sent: Friday, March 24, 2006 11:51 AM
>To: jdo-dev@db.apache.org; jdo-experts-ext@sun.com
>Subject: RE: serialize Detachable instance for storage
>
>
>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
>