From jdo-dev-return-735-apmail-db-jdo-dev-archive=www.apache.org@db.apache.org Wed Jul 13 23:02:58 2005 Return-Path: Delivered-To: apmail-db-jdo-dev-archive@www.apache.org Received: (qmail 95872 invoked from network); 13 Jul 2005 23:02:58 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 13 Jul 2005 23:02:58 -0000 Received: (qmail 37580 invoked by uid 500); 13 Jul 2005 23:02:43 -0000 Mailing-List: contact jdo-dev-help@db.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: jdo-dev@db.apache.org Delivered-To: mailing list jdo-dev@db.apache.org Received: (qmail 37488 invoked by uid 99); 13 Jul 2005 23:02:42 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 13 Jul 2005 16:02:42 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=HTML_60_70,HTML_MESSAGE X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: local policy) Received: from [192.18.98.36] (HELO brmea-mail-4.sun.com) (192.18.98.36) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 13 Jul 2005 16:02:38 -0700 Received: from fe2.sun.com ([192.18.108.79]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j6DN2dGY000977 for ; Wed, 13 Jul 2005 17:02:39 -0600 (MDT) Received: from conversion-daemon.fe2.sun.com by fe2.sun.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) id <0IJL007016RKW700@fe2.sun.com> (original mail from Craig.Russell@Sun.COM) for jdo-dev@db.apache.org; Wed, 13 Jul 2005 17:02:39 -0600 (MDT) Received: from [129.145.133.145] by fe2.sun.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0IJL00GDI9CEPYYC@fe2.sun.com> for jdo-dev@db.apache.org; Wed, 13 Jul 2005 17:02:39 -0600 (MDT) Date: Wed, 13 Jul 2005 16:02:44 -0700 From: Craig Russell Subject: Re: Detachment contract In-reply-to: <20050713195604.23360.qmail@web31809.mail.mud.yahoo.com> To: JDO Expert Group Cc: jdo-tck-ext@Sun.COM, jdo-dev@db.apache.org Message-id: <4605554F-570D-4FD0-B23D-F228055A43B4@Sun.COM> MIME-version: 1.0 X-Mailer: Apple Mail (2.733) Content-type: multipart/signed; protocol="application/pkcs7-signature"; boundary=Apple-Mail-12--892839136; micalg=sha1 References: <20050713195604.23360.qmail@web31809.mail.mud.yahoo.com> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N --Apple-Mail-12--892839136 Content-Type: multipart/alternative; boundary=Apple-Mail-11--892839508 --Apple-Mail-11--892839508 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi Geoff, Thanks for the feedback. On Jul 13, 2005, at 12:56 PM, Geoff hendrey wrote: > > >> The jdoDetachedState is an Object[ ] that consists >> of: >> >> { >> Object objectId, >> Object version, >> BitSet loadedFields, >> BitSet modifiedFields >> } >> > > > I also think it would be a nice improvement to make > loadedFields and modifiedFields accessible and useable > for non-detached classes. It's in good keeping with > Law of Demeter to keep this information as close to > the source as possible, instead of forcing the > StateManager to track it. > > We'd need to add jdoGetLoadedFields() and > jdoGetModifiedFields(). > > Or is there some reason this wouldn't work or doesn't > make sense? I'm not sold on the idea that we should make a user api out of these. We have survived the past 5 years without making this internal state visible, and I personally never heard anyone asking for it. I don't believe that requiring the State Manager to track loaded and modified fields violates the Law of Demeter (of which I am a huge fan, by the way). It is specifically *not* the responsibility or the concern of the Persistence Capable instance to know whether a field is loaded or modified. It *is* the responsibility of the State Manager to know this and to enforce the policy of the JDO implementation. In fact, the way the PC/SM contract is written, the PC doesn't know which fields are loaded. However, there is a valid reason for making the information standard when it is being externalized for detachment. The PC must be responsible for this information while detached. But it's arguably not the most efficient way to have the State Manager handle it, and it's not even required for the State Manager to keep the information in this form until externalization. So I would be against the requirement to have the State Manager track loaded and modified fields using this technique. And against the requirement to expose this state to user code. Others? Craig > > -geoff > > > > > > > ____________________________________________________ > Start your day with Yahoo! - make it your home page > http://www.yahoo.com/r/hs > > 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-11--892839508 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hi Geoff,

Thanks for the = feedback.

On Jul 13, 2005, at 12:56 PM, Geoff = hendrey wrote:

<AMEN>
=
The = jdoDetachedState is an Object[ ] that consists
of:

{
Object = objectId,
Object version,
BitSet loadedFields,
BitSet = modifiedFields
}

</AMEN>

I also think it would be a nice = improvement to make
loadedFields and = modifiedFields accessible and useable
for = non-detached classes. It's in good keeping with
Law of Demeter to keep this information as close = to
the source as possible, instead of forcing = the
StateManager=A0 to track it.

We'd = need to add jdoGetLoadedFields() and
=A0

Or is there = some reason this wouldn't work or doesn't
make = sense?

I'm not sold on the idea that we = should make a user api out of these. We have survived the past 5 years = without making this internal state visible, and I personally never heard = anyone asking for it.

I don't believe that = requiring the State Manager to track loaded and modified fields violates = the Law of Demeter (of which I am a huge fan, by the way). It is = specifically *not* the responsibility or the concern of the Persistence = Capable instance to know whether a field is loaded or modified. It *is* = the responsibility of the State Manager to know this and to enforce the = policy of the JDO implementation. In fact, the way the PC/SM contract is = written, the PC doesn't know which fields are loaded.=A0

However, there is a valid = reason for making the information standard when it is being externalized = for detachment. The PC must be responsible for this information while = detached. But it's arguably not the most efficient=A0 way to have the = State Manager handle it, and it's not even required for the State = Manager to keep the information in this form until = externalization.

So I would be against the = requirement to have the State Manager track loaded and modified fields = using this technique. And against the requirement to expose this state = to user code.

Others?

Craig

-geoff





=A0=A0 =A0 =A0 =A0

Start your day with Yahoo! - make it your home = page



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-11--892839508-- --Apple-Mail-12--892839136 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGHjCCAtcw ggJAoAMCAQICAw3FWTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDUwMTEwMDA0MTA5WhcNMDYwMTEwMDA0MTA5WjBHMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSQwIgYJKoZIhvcNAQkBFhVDcmFpZy5SdXNzZWxsQFN1 bi5DT00wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDti7ZE4rO6oXKbLM02AG9WY55t udmBVL53fb3V3X5S1kvcJOk1NEMIYT/T7Ww+/hE955zvHT29+mIoNe8AW/yj1WUH8uGG2HxhwCHI UQTHmN/ioVJgjwUaYbtNMKbL/NRpnL0QWewdMJS+6IFzFyX7ADFW5cJ+UWNLvNeWAQtN0mtLildn vdOgh50i8YPvACNkCHoomGjXx0azcXbe1X3c5AgRI6e2CZe5k2lRFQFUMqkjdoMtQPoNqJ1BxH9l i4cnabl8mcTwHHl44hrvb8ThqwRf2pfJh2vVuwmgK6z4IWjOk4RQM+0ODsRdq67mBdimJYmPMK1p RMBHzrUsfKxNAgMBAAGjMjAwMCAGA1UdEQQZMBeBFUNyYWlnLlJ1c3NlbGxAU3VuLkNPTTAMBgNV HRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAIj86LzxCHedStDLMEeqHLy+UFG7zIRHfChSIV42 +MvXicydXEBh8v0Ry1V2d/lY4jS78G5yW5R9fKt1U5nlRBCOVzdhomvSolnNRIT71wPVVDrAIVlA YpXKxSmVBq7+4hV+3ZLHDeq3qZnNmiJR0sTEUD16xZX1RJs9dRYPCHoRMIIDPzCCAqigAwIBAgIB DTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTES MBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMf Q2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29t MB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbL rzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZ cmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0 cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQD AgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0B AQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3h YWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1 TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAgMNxVkwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsG CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwNzEzMjMwMjQ1WjAjBgkqhkiG9w0BCQQxFgQU 4Giu0aabxjwJKkKq3TCBBhx5Wm8weAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMG A1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw3FWTB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMNxVkwDQYJKoZIhvcNAQEBBQAEggEA SoVUx7Y9/CE8MUsME7O/MS35n7ytMr6exjzBgJNqrxo6Ig7HKyPXx/p8IvWh1kOjnC4WIq26f6u0 V8AUftEPg0D+MeZC1jVSym7UMP5GyKsh5Cv+d0YOLSdEDq00hGeGUYgXl532n+9j4e7jKcVv8Qt5 otzdMn5MISl1T2HlCwniBJTxoi4Awq3/8rl8f5bFfjQfjs5oV+bcWvWAes1XHuZMBf46C2gkSivJ p7jxhETCB1hd+990vHHkRCkdShEbaRoy63Ot7g7xskHJICqVPBMJpC6mWB0d6tzfCkHXogIEiQPj irvXXv3ySUO+CK9Vx61zYSAZtmVuAb0iMUu1lAAAAAAAAA== --Apple-Mail-12--892839136--