Return-Path: Delivered-To: apmail-db-jdo-dev-archive@www.apache.org Received: (qmail 22337 invoked from network); 20 Dec 2005 22:05:01 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 20 Dec 2005 22:05:01 -0000 Received: (qmail 21465 invoked by uid 500); 20 Dec 2005 22:05:01 -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 21454 invoked by uid 99); 20 Dec 2005 22:05:01 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 20 Dec 2005 14:05:01 -0800 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=HTML_MESSAGE,UNPARSEABLE_RELAY 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; Tue, 20 Dec 2005 14:05:00 -0800 Received: from fe-amer-03.sun.com ([192.18.108.177]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id jBKM4eD7008659 for ; Tue, 20 Dec 2005 15:04:40 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IRT00C01H7XEF00@mail-amer.sun.com> (original mail from Craig.Russell@Sun.COM) for jdo-dev@db.apache.org; Tue, 20 Dec 2005 15:04:40 -0700 (MST) Received: from [129.145.133.145] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IRT000MRHBRN900@mail-amer.sun.com> for jdo-dev@db.apache.org; Tue, 20 Dec 2005 15:04:39 -0700 (MST) Date: Tue, 20 Dec 2005 14:04:37 -0800 From: Craig L Russell Subject: Issue 150: Consistency requirements for relationships with mapped-by Sender: Craig.Russell@Sun.COM To: JDO Expert Group , Apache JDO project Message-id: <71E343BA-982A-47B1-9AF0-33E03432A0A3@Sun.COM> MIME-version: 1.0 X-Mailer: Apple Mail (2.746.2) Content-type: multipart/signed; protocol="application/pkcs7-signature"; boundary=Apple-Mail-55-42771486; micalg=sha1 X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N --Apple-Mail-55-42771486 Content-Type: multipart/alternative; boundary=Apple-Mail-54-42770902 --Apple-Mail-54-42770902 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Javadogs, In chapter "15.3 Relationship Mapping" of the spec, "changes to the field mapped via mapped-by are not reflected in the datastore". However, this conflicts with the text that follows: "... the column(s) will be changed during commit and will therefore be visible by both sides in the next transaction.". I believe that the second part is more important than the first part. Specifically, if the user makes a change to a persistent field, at flush or commit time it makes sense to me that the implementation should make sure that the change is flushed to the datastore. Further, the spec says that changes will be visible by both sides in the next transaction, which has implications for RetainValues. I think it's technically feasible for changes to either side to be reflected in the database, and for RetainValues to be handled consistently. If two relationships (one on each side of an association) are mapped to the same column, the field on only one side of the association needs to be explicitly mapped. The field on the other side of the relationship can be mapped simply by using the mapped-by attribute identifying the field on the side that defines the mapping. Regardless of which side changes the relationship, flush (whether done as part of commit or explicitly by the user) will modify the datastore to reflect the change. There is no further relationship implied by having both sides of the relationship map to the same database column(s). In particular, making a change to one side of the relationship does not imply any runtime behavior by the JDO implementation to change the other side of the relationship in memory prior to flush and will therefore be visible by both sides in the next transaction. If the RetainValues flag or DetachAllOnCommit is set to true, and the relationship field is loaded, then the implementation will change the field on the other side so it is visible after transaction completion. Conflicting changes to relationships cause a JDOUserException to be thrown at flush time. Conflicting changes include: adding a related instance with a single-valued mapped-by relationship field to more than one one-to-many collection relationship setting both sides of a one-to-one relationship such that they do not refer to each other 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-54-42770902 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Javadogs,

In chapter = "15.3 Relationship Mapping" of the spec, "changes to the field mapped = via mapped-by are not reflected in the datastore".

However, this conflicts with the text that = follows:

=A0"... the = column(s) will be changed during commit and will therefore be visible by = both sides in the next transaction.".

I believe = that the second part is more important than the first part. = Specifically, if the user makes a change to a persistent field, at flush = or commit time it makes sense to me that the implementation should make = sure that the change is flushed to the datastore. Further, the spec says = that changes will be visible by both sides in the next transaction, = which has implications for RetainValues.

I think it's = technically feasible for changes to either side to be reflected in the = database, and for RetainValues to be handled consistently.

If two relationships = (one on each side of an association) are mapped to the same column, the = field on only one side of the association needs to be explicitly = mapped.

The field on the other side of the relationship can be = mapped simply by=A0using the mapped-by attribute=A0identifying the field = on the side that defines the mapping. Regardless of which side changes = the relationship, flush (whether done as part of commit or explicitly by = the user) will modify the datastore to reflect the change. There is no = further relationship implied by having both sides of the relationship = map to the same database column(s). In particular, making a change to = one side of the relationship does not imply any runtime behavior by the = JDO implementation to change the other side of the relationship in = memory prior to flush=A0and will therefore be visible by both sides in = the next transaction. If the RetainValues flag or DetachAllOnCommit is = set to true, and the relationship field is loaded, then the = implementation will change the field on the other side so it is visible = after transaction completion.

Conflicting changes to = relationships cause a JDOUserException to be thrown at flush time. = Conflicting changes include:=A0

adding a related instance with = a single-valued mapped-by relationship field to more than one = one-to-many collection relationship

setting both sides of a = one-to-one relationship such that they do not refer to each = other

</proposed 15.3>

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-54-42770902-- --Apple-Mail-55-42771486 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 CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUxMjIwMjIwNDM3WjAjBgkqhkiG9w0BCQQxFgQU xkIrE5UJddst9dYy7cZSuoq/nP0weAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMG A1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw3FWTB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMNxVkwDQYJKoZIhvcNAQEBBQAEggEA zdKnu4y8Jk/iGit22LvPbQYo7/Li8LXKOfB2rW4vH1ZNKTLOG/EWvpVVHjPu6HOlqFukTBLWSLm5 0iO3DQlVdwSSvT+KTV3DPqHcALnaksz2RVR8bD5poBmCr5hiBoIN+28HrRwA0vvD9qQ/R0sRjm39 4sdoPi2Ku82HSMTRj+LqVdh8hSds+/2aMA9REEiiQKbZEUDRqhxhyUavs06nZhPiPxtTRBJfDrC7 KWEGDbzoopRyC2oGkAc1YV+DUIhoeMYaz4Rv7C0bjuJkpNusrSZia1aB5IpBY4cBEN6Onmv4aO4Z rmxfInzPwtqDDln6DLVolhYX6jkjGjVXtDhmJQAAAAAAAA== --Apple-Mail-55-42771486--