db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matthew T. Adams" <matt...@matthewadams.org>
Subject RE: 2.1 Spec: detached-dirty parameters to makePersistent() when DetachAllOnCommit=true
Date Thu, 09 Aug 2007 16:42:54 GMT
I think I prefer Andy's less verbose "CopyOnAttach", with a value of true by
default.  I found it to be quite clear while reading the thread, and, no
offense, Craig, but I couldn't figure out what you meant by
"CopyOnMakePersistent", and "CopyDetachedOnMakePersistent" doesn't exactly
roll off of the tongue.  Now, if we add CopyOnAttach, should we also have
CopyOnDetach (true by default) or DetachInPlace (false by default), or do we
just say that the only way to detach in place is via DetachAllOnCommit?  I'm
for saying that the only way to detach in place is via DetachAllOnCommit.

As far as having defaults for defaults, Xcalia has had that for quite a
while.  I'm not sure about other implementations; I'd have to check.  After
a while, though, it starts to get crazy, especially when you start talking
about the default value (false) of the default
(javax.jdo.option.DetachableByDefault) that determines another default value
(detachable/@Detachable). :)

Perhaps it is reasonable to begin specifying default values for options
whose defaults aren't currently specified.  Is there currently a list of
those?  Said list would be nice; without it, we'd have to search for the
absence of something, and those "not" searches are always exhaustive...me no


-----Original Message-----
From: Craig.Russell@Sun.COM [mailto:Craig.Russell@Sun.COM] 
Sent: Thursday, August 09, 2007 8:07 AM
To: Andy Jefferson
Cc: jdo-dev@db.apache.org; JDO Expert Group
Subject: Re: 2.1 Spec: detached-dirty parameters to makePersistent() when



On Aug 8, 2007, at 11:31 PM, Andy Jefferson wrote:

> Hi,
>>> So if we introduce a flag that uses the same instance on attach, we
>>> might want to have the flag called CopyOnMakePersistent and have
>>> true be the current specified behavior and false be the new
>>> behavior we've been discussing.
>> Sounds great to me.  There's some fine print here, though:  Just
>> because CopyOnMakePersistent is set to true, that doesn't mean that
>> makePersistent() will *always* return copies.  For example, current
>> specified behavior says that when DetachAllOnCommit=false and calling
>> makePersistent() with a transient parameter, the returned object will
>> be the same instance, now transitioned to persistent-clean.  This
>> behavior won't change because of our new option (regardless of
>> whether it is set to true or false), and we don't want folks to be
>> confused about that...
> I prefer the name you suggested to the one I originally wrote.  
> Comments :-
> 1. "DetachAllOnCommit" has no bearing on what makePersistent() does  
> - it
> defines what happens on tx.commit() only. makePersistent will  
> (currently)
> return the original object if persisting a transient and return a  
> copy if
> attaching.
> 2. How about calling it CopyOnAttach ? makePersistent has two  
> roles ...
> persisting new, and attaching detached. I don't ever see a need to add
> control to the operation of persisting a new object, so the
> name "CopyOnAttach" distinguishes to just the attach process.
> -- 
> Andy  (Java Persistent Objects - http://www.jpox.org)

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!

View raw message