Hi,

attached you find some changes of the api20 project. It adds method
isDetached to the StateManager interface and add since tags to two PM
methods.

Regards Michael

--
Michael Bouschen		Tech@Spree Engineering GmbH
mailto:mbo.tech@spree.de	http://www.tech.spree.de/
Tel.:++49/30/235 520-33		Buelowstr. 66
Fax.:++49/30/2175 2012		D-10783 Berlin

[ Post a follow-up to this message ]

[ Post a follow-up to this message ]

Hi Craig,

thanks!

One more question: does the enhancer generated method jdoGetVersion
delegate to the StateManager? I think it should, so I propose I add the
following method to the StateManager:

/** Return the object representing the version of the calling instance.
* @param pc the calling <code>PersistenceCapable</code> instance
* @return the object representing the version of the calling instance.
*/
Object getVersion (PersistenceCapable pc);

What do you think?

Regards Michael

> Hi Michael,
>
> Looks good to check in.
>
> Craig
>
> On Jun 26, 2005, at 1:55 PM, Michael Bouschen wrote:
> 
>
> Craig Russell
>
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
>
> 408 276-5638 mailto:Craig.Russell@sun.com
>
> P.S. A good JDO? O, Gasp!
>
>


--
Michael Bouschen		Tech@Spree Engineering GmbH
mailto:mbo.tech@spree.de	http://www.tech.spree.de/
Tel.:++49/30/235 520-33		Buelowstr. 66
Fax.:++49/30/2175 2012		D-10783 Berlin

[ Post a follow-up to this message ]

> attached you find some changes of the api20 project. It adds method
> isDetached to the StateManager interface and add since tags to two PM
> methods.

Hi Michael,

when an object is detached it doesn't have a StateManager, hence the
jdoIsDirty() method added to PC instances during enhancement is typically
based on whether it has an objectId and state manager in the instance. Hence
my question is, why do we need this method ?

--
Andy
Java Persistent Objects - JPOX

[ Post a follow-up to this message ]

> when an object is detached it doesn't have a StateManager, hence the
> jdoIsDirty() method added to PC instances during enhancement is typically
> based on whether it has an objectId and state manager in the instance.
> Hence my question is, why do we need this method ?

I did of course mean to say "the jdoIsDetached() method".

--
Andy
Java Persistent Objects - JPOX

[ Post a follow-up to this message ]

Hi Andy,

this is just for JDO implementations that decide to keep the
StateManager for detached instances. The enhancer generated code for
jdoIsDetached needs to check whether there is a StateManager anyway. If
so it should delegate to it, if not it should check for the objectId.
What do you think?

Regards Michael
 
>
>
> I did of course mean to say "the jdoIsDetached() method".
>


--
Michael Bouschen		Tech@Spree Engineering GmbH
mailto:mbo.tech@spree.de	http://www.tech.spree.de/
Tel.:++49/30/235 520-33		Buelowstr. 66
Fax.:++49/30/2175 2012		D-10783 Berlin

[ Post a follow-up to this message ]

> this is just for JDO implementations that decide to keep the
> StateManager for detached instances. The enhancer generated code for
> jdoIsDetached needs to check whether there is a StateManager anyway. If
> so it should delegate to it, if not it should check for the objectId.
> What do you think?

Hi Michael,

Well I've no particular problem with the idea, but I seem to have missed the
discussion in the EG that we are even allowing StateManagers for detached
instances.


Some time back when we were discussing serialisation of detacheds I seem to
remember that it was decided not to have this. Maybe I misunderstood what wa
s
being discussed.

What happens if someone passes a detached instance (that has no SM) across t
o
a JDO impl that needs a SM while detached ? What is the detached SM doing ?
(presumably keeping some track of what fields have changed - even though we
already have these fields stored in the BitSet).
What if JDO Impl 1 requires a StateManager while detached, and then the
detached instance is serialised. It is then passed to another app server and
the user tries to deserialise it. It is presumably going to try to
deserialise the SM, but JDO Impl1 classes aren't present on this app server.

If a detached instance can sometimes have a StateManager (dependent on the
implementation) then the spec should state that it is for the implementation
to decide whether to use them whilst detached. I don't see this currently.


--
Andy
Java Persistent Objects - JPOX

[ Post a follow-up to this message ]

Hi Andy,

good question! I will not check in the StateManager changes before this
has been resolved. I hope that Craig can clarify.

Regards Michael
 
>
>
> Hi Michael,
>
> Well I've no particular problem with the idea, but I seem to have missed t
he
> discussion in the EG that we are even allowing StateManagers for detached
> instances.
>
>
> Some time back when we were discussing serialisation of detacheds I seem t
o
> remember that it was decided not to have this. Maybe I misunderstood what 
was
> being discussed.
>
> What happens if someone passes a detached instance (that has no SM) across
 to
> a JDO impl that needs a SM while detached ? What is the detached SM doing 
?
> (presumably keeping some track of what fields have changed - even though w
e
> already have these fields stored in the BitSet).
> What if JDO Impl 1 requires a StateManager while detached, and then the
> detached instance is serialised. It is then passed to another app server a
nd
> the user tries to deserialise it. It is presumably going to try to
> deserialise the SM, but JDO Impl1 classes aren't present on this app serve
r.
>
> If a detached instance can sometimes have a StateManager (dependent on the
> implementation) then the spec should state that it is for the implementati
on
> to decide whether to use them whilst detached. I don't see this currently.
>
>


--
Michael Bouschen		Tech@Spree Engineering GmbH
mailto:mbo.tech@spree.de	http://www.tech.spree.de/
Tel.:++49/30/235 520-33		Buelowstr. 66
Fax.:++49/30/2175 2012		D-10783 Berlin

[ Post a follow-up to this message ]