Two issues here. On Aug 9, 2007, at 9:42 AM, Matthew T. Adams wrote:
1. I've woken up sufficiently to realize that while the API is makePersistent, the functionality is attach, so I'll agree that CopyOnAttach is much clearer. Now I have to go make sure the usage of "attach" is consistent in the specification.
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, nooffense, 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.
2. I have no issue with going back and specifying defaults for all of the properties we have. There was some objection early in the process to mandating defaults but I'd be happy to revisit these.
Craig
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 talkingabout 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 nolikey. -matthew -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, August 09, 2007 8:07 AM To: Andy Jefferson Cc: [email protected]; JDO Expert GroupSubject: Re: 2.1 Spec: detached-dirty parameters to makePersistent () whenDetachAllOnCommit=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, currentspecified behavior says that when DetachAllOnCommit=false and calling makePersistent() with a transient parameter, the returned object willbe 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 addcontrol 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!
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
