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 likey. -matthew -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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 DetachAllOnCommit=true CopyDetachedOnMakePersistent? Craig 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:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
