db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From cbeams <cbe...@gmail.com>
Subject Re: 2.1 Spec: detached-dirty parameters to makePersistent() when DetachAllOnCommit=true
Date Tue, 07 Aug 2007 18:52:04 GMT

On Aug 7, 2007, at 11:35 AM, Andy Jefferson wrote:

> You could allow something of this form by imposing a restriction  
> that if an
> object needs attaching, and that "AttachOnPersist" flag is set, and  
> the PM
> already has a persistent object with that id then throw a  
> JDOUserException.
> Clearly the primary use-case is where the user detaches a single  
> object, and
> then wants to attach the same thing, so they typically never hit the
> duplicate detached object issue.

You're right about the primary use case.  With this restriction in  
place, however, would I be able to do the following?

import static javax.jdo.JDOHelper.*;

assert pm.getAttachOnPersist() == true;
assert pm.getDetachAllOnCommit() == true;

// fetch a detched object
Query q = pm.newQuery(Foo.class);
Foo foo = (Foo) q.execute();

// my foo object is now detached-clean
assert isDetached(foo) && !isDirty(foo);

// make it dirty:

// attach

// should be transitioned back to detached-clean
assert isDetached(foo) && !isDirty(foo);

// dirty it once more

// and attach it a second time - wouldn't this cause the  
JDOUserException you mention above?  The pm is already managing (by  
ID, I assume) this object, so how would it know the difference  
between the application 'detaching and attaching two separate  
instances of the same object' and simply 'attaching twice the same  
instance of an object'?  Hopefully I'm missing something, because I  
like the proposed solution.

// again, should now be detached-clean
assert isDetached(foo) && !isDirty(foo);

- Chris

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message