Mailing-List: contact jdo-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jdo-dev@db.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Date: Thu, 09 Aug 2007 09:49:36 -0700
From: Craig L Russell <Craig.Russell@Sun.COM>
Subject: Re: 2.1 Spec: detached-dirty parameters to makePersistent() when
 DetachAllOnCommit=true
In-reply-to: <039b01c7daa4$5626e5f0$0274b1d0$@org>
Sender: Craig.Russell@Sun.COM
To: "Matthew T. Adams" <matthew@matthewadams.org>
Cc: jdo-dev@db.apache.org, "'Andy Jefferson'" <andy@jpox.org>,
        "'JDO Expert Group'" <jdo-experts-ext@Sun.COM>
Message-id: <D066B919-2ECA-49CA-9A91-B3F4842FD3D0@SUN.com>
MIME-version: 1.0
Content-type: multipart/signed; protocol="application/pkcs7-signature";
 boundary=Apple-Mail-280-65062477; micalg=sha1
References: <45CA023F-9583-4BA6-BD8F-1A2F7149F5C2@gmail.com>
 <6322D489-E59C-458D-961A-0CDFF10447CC@SUN.com>
 <6F43BE4A-40C9-46B1-A947-1EDAA7E91E02@gmail.com>
 <200708090731.32176.andy@jpox.org>
 <54D8B6C4-ED48-454A-9A59-69F3FD33A4C6@SUN.com>
 <039b01c7daa4$5626e5f0$0274b1d0$@org>

--Apple-Mail-280-65062477
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

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!


--Apple-Mail-280-65062477
Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Disposition: attachment;
	filename=smime.p7s

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGUDCCAwkw
ggJyoAMCAQICECpJVMO68ii+Xfsc1O1YYFIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx
JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ
ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MTIwOTE5NTEwNVoXDTA3MTIwOTE5NTEw
NVowbDEQMA4GA1UEBBMHUnVzc2VsbDEUMBIGA1UEKhMLQ3JhaWcgTGFpcmQxHDAaBgNVBAMTE0Ny
YWlnIExhaXJkIFJ1c3NlbGwxJDAiBgkqhkiG9w0BCQEWFUNyYWlnLlJ1c3NlbGxAU3VuLkNPTTCC
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMNAB4Ih+ShsCt89HzqIdwEx8L4o1UHiY6V7
16mrCedfd4Y0/uI7z9Zam8ysgEh+F7aDnQEKmEsVFN35G4nPMfLU6dZYkvADwUjbq82t/dJ3FDDg
Q945nHHpqECZff/S/UMho9AFfj6PZvZBAlDCJAayb4RdKIlfuvPW9YcQStQ1IfVJcVuKnC0Q+tdc
a4A7zn7IzLOQohO1lTc3hXSBigEIGiGYn6Ny0wmexfA3X1WsXekFx5czd+M4GjDjswn8CNoBmnBr
jOTGK1mOsXR6GSRHnly2s9xTdE4qv9qimM+7C2yzMHbKcszV7OQoLsRsZKDh+6u9wYU+TrjcY4ym
bA8CAwEAAaMyMDAwIAYDVR0RBBkwF4EVQ3JhaWcuUnVzc2VsbEBTdW4uQ09NMAwGA1UdEwEB/wQC
MAAwDQYJKoZIhvcNAQEFBQADgYEAU/EpPDztnb55Fz7iGSVm1mYEVj5m2OQKTYG26POUAomCBRrt
/CdBBvqYmcHUTpra0qLELHAQadYFl2v11iQkqwF5PPJs19oU/zA0m5qFnOMTAiCvel7IprIwA2r6
eJR9siaPwDRgVJ/Sj71dD+utwf+nRrNy0/7PMNK5y+ocsYQwggM/MIICqKADAgECAgENMA0GCSqG
SIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQH
EwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZp
Y2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1h
aWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMw
NzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3Rl
IENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWls
IElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5owHUE
cJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH5/Ef
kTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7AgMB
AAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8vY3Js
LnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDALBgNVHQ8EBAMCAQYwKQYD
VR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0GCSqGSIb3DQEBBQUAA4GB
AEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQcUCCTcDz9reFhYsPZOhl+
hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC
3CEZNd4ksdMdRv9dX2VPMYIDEDCCAwwCAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh
d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt
YWlsIElzc3VpbmcgQ0ECECpJVMO68ii+Xfsc1O1YYFIwCQYFKw4DAhoFAKCCAW8wGAYJKoZIhvcN
AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcwODA5MTY0OTM2WjAjBgkqhkiG9w0B
CQQxFgQUQCmidSK+QesforqxrcWexHhBxAQwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMC
WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0
ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAqSVTDuvIovl37HNTtWGBSMIGHBgsqhkiG
9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ
dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAq
SVTDuvIovl37HNTtWGBSMA0GCSqGSIb3DQEBAQUABIIBACiwoUv8+pZxX+YMd10y89XeEWpB/sek
nqXDpCH7MphMwtFOy6Df2gcvgEyXTrVR9Ci0BmqyfRfwN8UnDMmx+v7x3HYLm/fRBqylbMTFIGKz
fbDqsKGcLkzmrC5gUSAPr9lofdBpt4f7Y8AmLGbaKadsJv6XS/4iu7IbmFnnbKcpaX/+tAspyv+F
6wUDSA62FWNDX8Tj0hvoikGM+319tpEZIx5PX9CFF+V6KTAQ308xDCjlv1fO5Hnjo5TVk41neMvM
IlbguZ54Sl5TOBc3nqkdY31+03lCN+XI9zHl6y1qX4MJzCiCDcIH2h3pDV7gaPpqxfDnpajXaf89
oITYoy8AAAAAAAA=

--Apple-Mail-280-65062477--