db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Re: 2.1 Spec: detached-dirty parameters to makePersistent() when DetachAllOnCommit=true
Date Thu, 09 Aug 2007 16:49:36 GMT
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, 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.
>

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  
> 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: 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
> 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:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
>

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!


Mime
View raw message