Re: serialize Detachable instance for storage

Craig L Russell Fri, 24 Mar 2006 17:40:07 -0800

Hi,

I agree on all points as well. I'll add this to the errata for JDO maintenance.

By the way, Andy, if you have a test case that you can point me to (I hope it's in the repository) we can add it to the TCK or at least implement the ideas contained therein.


Thanks,

Craig

On Mar 24, 2006, at 12:22 PM, Matthew T. Adams wrote:

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:[EMAIL PROTECTED]
Sent: Friday, March 24, 2006 11:51 AM
To: [email protected]; [EMAIL PROTECTED]
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


Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!

smime.p7s
Description: S/MIME cryptographic signature

Re: serialize Detachable instance for storage

Reply via email to