Mailing-List: contact jdo-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jdo-dev@db.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Date: Fri, 08 Aug 2008 09:33:24 -0700
From: Craig L Russell <Craig.Russell@Sun.COM>
Subject: Re: Bidirectional relationship tests in the TCK
In-reply-to: <484E73E9.2030409@artnology.com>
Sender: Craig.Russell@Sun.COM
To: jdo-dev@db.apache.org
Message-id: <E4083F70-1163-4220-BFDF-0632E2E79238@SUN.com>
MIME-version: 1.0
Content-type: multipart/signed; protocol="application/pkcs7-signature";
 micalg=sha1; boundary=Apple-Mail-9--612163155
References: <483C3C1A.9010501@artnology.com>
 <7BCCC389-35CA-41E2-A009-5194769AAE17@SUN.com>
 <48497443.7070004@artnology.com>
 <0C0C35FC-10AA-4734-91CA-3B02265588CA@SUN.com>
 <484CED20.5080409@artnology.com>
 <65CC0AF6-4CFF-461C-99E3-D6A7002D70E9@SUN.com>
 <484E73E9.2030409@artnology.com>

--Apple-Mail-9--612163155
Content-Type: text/plain;
	charset=ISO-8859-1;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: quoted-printable

Hi J=F6rg,
On Jun 10, 2008, at 5:30 AM, Joerg von Frantzius wrote:

> Craig L Russell schrieb:
>> Hi J=F6rg,
>>
>> On Jun 9, 2008, at 1:43 AM, Joerg von Frantzius wrote:
>>
>>> Hello Craig,
>>>
>>> what I really meant was: when modifying state of bidirectional =20
>>> associations on detached objects, should those detached objects =20
>>> immediately reflect consistent bidirectional state in the VM even =20=

>>> before attaching? E.g. set a one-to-one association from one side, =20=

>>> and immediately see the newly associated object from the other side.
>>
>> Well, no. Detached objects are not associated with a =20
>> PersistenceManager and so flush() or commit() cannot by definition =20=

>> be applied to them. So there is no specified behavior that applies =20=

>> to relationships of detached objects.
>>>
>>> "15.3 Relationship Mapping" says that "Regardless of which side =20
>>> changes the relationship,
>>> flush (whether done as part of commit or explicitly by the user) =20
>>> will modify the datastore to
>>> reflect the change and will update the memory model for =20
>>> consistency."
>>>
>>> There is no flush when modifying detached objects, so this doesn't =20=

>>> really sound like the memory model should get updated before the =20
>>> detached objects are attached again and a flush actually happens. =20=

>>> =46rom an application programmer's point of view, it would of course =
=20
>>> be desirable if behaviour was consistent both in attached and =20
>>> detached state.
>>
>> It is consistent. If you flush or commit, all the specified =20
>> behavior occurs, regardless of where the changes were made =20
>> (attached or detached).
> That leads me to the question: why is the memory model to be updated =20=

> only after flush()?
>
> When I set an association and read it afterwards from the same side =20=

> that I modified, I'll immediately see my changes without having to =20
> call flush() inbetween. So the behaviour for "seeing results of =20
> association modification" is depending on which side of the =20
> association I'm looking at. I wonder if that is really necessary? =20
> IMHO, it would be more consistent if an application programmer =20
> didn't have to think about which side of a bidirectional association =20=

> (s)he is looking at.

Yes, you can make a case for the jdo implementation immediately =20
updating the other side of a managed relationship. However, it's not =20
clear to me that the jdo implementation is the right place to do this.

The rationale for the currently specified behavior is this:

There is only one datastore artifact (the foreign key) that represents =20=

both sides of the relationship. So at flush (when the jdo =20
implementation synchronizes the state of memory and datastore) both =20
sides of the memory relationship must be consistent with the datastore =20=

artifact.

Between beginning a transaction and flushing the changed state to the =20=

datastore, there is no other defined consistency point. =46rom an =20
application perspective, there is no point at which the application is =20=

done making changes that are supposed to be consistent. That is, =20
consistency of the memory model may change during processing.

If you're looking for consistency in memory, the application is free =20
to implement whatever behavior is appropriate to ensure consistency, =20
including modeling the relationship as a separate object and using =20
methods to manage the relationship instances.

But even then, there is time between setting one side of the =20
relationship and setting the other side to be consistent. So the =20
memory model always has a delay during which time the memory model is =20=

inconsistent. So it's a matter of defining the consistency point where =20=

both sides are supposed to be consistent with each other. In the case =20=

of jdo, there is a natural consistency point that we've used for other =20=

cases, such as construction of a new instance. We don't assume the =20
newly constructed instance is self-consistent until flush.

Regards,

Craig
>
>>
>> Once the detached object is brought into the domain of a =20
>> PersistenceManager via makePersistent, the flush and commit =20
>> behavior applies.
>>
>> Regards,
>>
>> Craig
>>>
>>>
>>> Regards,
>>> J=F6rg
>>>
>>> Craig L Russell schrieb:
>>>> Hi J=F6rg,
>>>>
>>>> On Jun 6, 2008, at 10:30 AM, Joerg von Frantzius wrote:
>>>>
>>>>> Sorry for not having had any time to look into this more =20
>>>>> thoroughly yet. I'll hopefully find it next week.
>>>>>
>>>>> I think I experienced problems with changing bidirectional =20
>>>>> relationships on detached objects. Now I'm not sure whether the =20=

>>>>> spec intended those to be managed as well?
>>>>
>>>> Sure, any change to a persistent field of a detached object =20
>>>> should be reflected in the database upon reconnection and commit.
>>>>
>>>> If you can write a test case, we'd be happy to consider adding it =20=

>>>> to the TCK.
>>>>
>>>> Craig
>>>>>
>>>>>
>>>>> Craig L Russell schrieb:
>>>>>> HI J=F6rg,
>>>>>>
>>>>>> On May 27, 2008, at 9:51 AM, Joerg von Frantzius wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> when looking at the relationship tests in =20
>>>>>>> org.apache.jdo.tck.mapping, it seems that the tests for =20
>>>>>>> bidirectional integrity only test changing relationships from =20=

>>>>>>> the "mapped-by" side of the relationship? That's my impression =20=

>>>>>>> at least from looking at the method names e.g. in =20
>>>>>>> Relationship1ToManyAllRelationships.java.
>>>>>>
>>>>>> There are a few relationship tests, and the intent was (is) to =20=

>>>>>> test changing relationships from both sides.
>>>>>>
>>>>>> If you can't find what you're looking for (in all the tests) =20
>>>>>> please let us know.
>>>>>>
>>>>>> Craig
>>>>>>>
>>>>>>>
>>>>>>> I'm asking this because I believe to see inconsistencies with =20=

>>>>>>> bidirectional relationships in the RI.
>>>>>>>
>>>>>>> Regards,
>>>>>>> J=F6rg
>>>>>>>
>>>>>>> --=20
>>>>>>> =
____________________________________________________________________
>>>>>>> artnology GmbH - Milastra=DFe 4 - 10437 Berlin - Germany
>>>>>>> Gesch=E4ftsf=FChrer: Ekkehard Blome (CEO), Felix Kuschnick (CCO)
>>>>>>> Registergericht: Amtsgericht Berlin Charlottenburg HRB 76376 =20
>>>>>>> UST-Id. DE 217652550
>>>>>>>
>>>>>>
>>>>>> 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!
>>>>>>
>>>>>
>>>>>
>>>>> --=20
>>>>> =
____________________________________________________________________
>>>>> artnology GmbH - Milastra=DFe 4 - 10437 Berlin - Germany
>>>>> Gesch=E4ftsf=FChrer: Ekkehard Blome (CEO), Felix Kuschnick (CCO)
>>>>> Registergericht: Amtsgericht Berlin Charlottenburg HRB 76376 UST-=20=

>>>>> Id. DE 217652550
>>>>>
>>>>
>>>> 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!
>>>>
>>>
>>>
>>> --=20
>>> ____________________________________________________________________
>>> artnology GmbH - Milastra=DFe 4 - 10437 Berlin - Germany
>>> Gesch=E4ftsf=FChrer: Ekkehard Blome (CEO), Felix Kuschnick (CCO)
>>> Registergericht: Amtsgericht Berlin Charlottenburg HRB 76376 UST-=20
>>> Id. DE 217652550
>>>
>>
>> Craig Russell
>> Architect, Sun Java Enterprise System http://java.sun.com/products/=20=

>> jdo
>> 408 276-5638 mailto:Craig.Russell@sun.com
>> P.S. A good JDO? O, Gasp!
>>
>
>
> --=20
> ____________________________________________________________________
> artnology GmbH - Milastra=DFe 4 - 10437 Berlin - Germany
> Gesch=E4ftsf=FChrer: Ekkehard Blome (CEO), Felix Kuschnick (CCO)
> Registergericht: Amtsgericht Berlin Charlottenburg HRB 76376 UST-Id. =20=

> DE 217652550
>

Craig L 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-9--612163155
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGUDCCAwkw
ggJyoAMCAQICECvOQSuIjHMvOZRC95BRg/wwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx
JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ
ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MTIxMDE1MjM1MVoXDTA4MTIwOTE1MjM1
MVowbDEQMA4GA1UEBBMHUnVzc2VsbDEUMBIGA1UEKhMLQ3JhaWcgTGFpcmQxHDAaBgNVBAMTE0Ny
YWlnIExhaXJkIFJ1c3NlbGwxJDAiBgkqhkiG9w0BCQEWFUNyYWlnLlJ1c3NlbGxAU3VuLkNPTTCC
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKzqGlLUastboCRqc0iBoTz2ODcqpMpEyPUo
nYtluchkSIoWzOW63AuoTczRt9sKfhwoK5mope+62B6Li06WJabm2UHqKAaNSuMHLsmyqvOdwbSt
enY7/HxOSCMqVoyVBTRJc2M8feCSVgi7ptGq9cM+Maa64R1/p9zqaQNucceU/1uper90bWplsjAT
rHgicgr9XJIQb6uYjhjlgxxnY/aispnCvLxMX+CiA2FWeeJTI7AiFlLwibTXYF4v12ToByvXtTiJ
knuND8qpwhK3Wp0tL4ae8mZ0nlKjCuNnqh99ZyEyTFHZBfVx8WSWRXkY4qxCG/IDQUo7WUaefOQT
1mECAwEAAaMyMDAwIAYDVR0RBBkwF4EVQ3JhaWcuUnVzc2VsbEBTdW4uQ09NMAwGA1UdEwEB/wQC
MAAwDQYJKoZIhvcNAQEFBQADgYEAEqfFNFoch0QPVKWJ4maAZl3MJD10yMeWt5xb+WNSkhYKHD8I
42E8tpdE3kmc5wp2cZrz9JqJF/KCQ/gI4pmDk1qpTs5pvXzFNiD5Lu5eLza4iyxSlTHUXcCnyNC6
4m0qC8p4m/51NEql5hyacj/+vdlEe5dygpyNGUCiyA/SdAswggM/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
YWlsIElzc3VpbmcgQ0ECECvOQSuIjHMvOZRC95BRg/wwCQYFKw4DAhoFAKCCAW8wGAYJKoZIhvcN
AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDgwODA4MTYzMzI1WjAjBgkqhkiG9w0B
CQQxFgQU8NmwhQFXPHvjrDXf+9KsZWXO6ZAwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMC
WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0
ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhArzkEriIxzLzmUQveQUYP8MIGHBgsqhkiG
9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ
dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAr
zkEriIxzLzmUQveQUYP8MA0GCSqGSIb3DQEBAQUABIIBAEp3PEHZurGHCXxp//X4++kQIL7irZ+u
TFjBqstmhBVezmxj02uS7iIcvQH9qXkEZw6rkmJ2h9G/E15kpXw/KgdVJIiBHx54zC0Q4n7jZARa
iEpUkjaHvjls7MPtQVnL596UVRydbPnnul0S4o0CoyhK1ozjfIKahovMFgqbTvulSMCXsJ/C7cZ9
sjSuvTGRQ7cVtPV4aV2E5fFe2R0oECwFIwdQhuHh5zScm6FrKXebypfKxae3EFxVEMY0RgdzEH9I
nkqnueKSLvoFJ8Z39SmXyC3wacWv8NNd6tUEfHP/iia7yyMgq8UNjrX7j1topDLU0FjgMqdqNT37
/s2aa9QAAAAAAAA=

--Apple-Mail-9--612163155--