|
View:
New views
11 Messages
—
Rating Filter:
Alert me
|
|
|
Bidirectional relationship tests in the TCKHi,
when looking at the relationship tests in org.apache.jdo.tck.mapping, it seems that the tests for bidirectional integrity only test changing relationships from the "mapped-by" side of the relationship? That's my impression at least from looking at the method names e.g. in Relationship1ToManyAllRelationships.java. I'm asking this because I believe to see inconsistencies with bidirectional relationships in the RI. Regards, Jörg -- ____________________________________________________________________ artnology GmbH - Milastraße 4 - 10437 Berlin - Germany Geschäftsführer: Ekkehard Blome (CEO), Felix Kuschnick (CCO) Registergericht: Amtsgericht Berlin Charlottenburg HRB 76376 UST-Id. DE 217652550 |
|
|
Re: Bidirectional relationship tests in the TCKHi Jörg,
There are tests from both sides: 10:50:09 /cygdrive/c/jdo/trunk/tck2/src/java/org/apache/jdo/tck/mapping>grep MappedSide *.java | grep public Relationship1To1AllRelationships.java: public void testSetToExistingFromMappedSide() { Relationship1To1AllRelationships.java: public void testSetToNullFromMappedSide() { Relationship1To1AllRelationships.java: public void testSetToNewFromMappedSide() { Relationship1To1AllRelationships.java: public void testDeleteFromMappedSide() { Relationship1To1NoRelationships.java: public void testSetToExistingFromMappedSide() { Relationship1To1NoRelationships.java: public void testSetToNewFromMappedSide() { Relationship1ToManyAllRelationships.java: public void testSetToExistingFromMappedSide() { Relationship1ToManyAllRelationships.java: public void testSetToNullFromMappedSide() { Relationship1ToManyAllRelationships.java: public void testSetToNewFromMappedSide() { Relationship1ToManyAllRelationships.java: public void testDeleteFromMappedSide() { Relationship1ToManyNoRelationships.java: public void testSetToExistingFromMappedSide() { Relationship1ToManyNoRelationships.java: public void testSetToNewFromMappedSide() { RelationshipManyToManyAllRelationships.java: public void testSetToNullFromMappedSide() { RelationshipManyToManyAllRelationships.java: public void testReplaceFromMappedSide() { RelationshipManyToManyAllRelationships.java: public void testAddNewFromMappedSide() { RelationshipManyToManyAllRelationships.java: public void testAddExistingFromMappedSide() { RelationshipManyToManyAllRelationships.java: public void testRemoveFromMappedSide() { RelationshipManyToManyAllRelationships.java: public void testDeleteFromMappedSide() { RelationshipManyToManyNoRelationships.java: public void testAddFromMappedSide() { RelationshipManyToManyNoRelationships.java: public void testReplaceFromMappedSide() { 10:47:42 /cygdrive/c/jdo/trunk/tck2/src/java/org/apache/jdo/tck/mapping>grep Mapped[bB]y *.java | grep public Relationship1To1AllRelationships.java: public void testSetToExistingFromMappedBySide() { Relationship1To1AllRelationships.java: public void testSetToNullFromMappedBySide() { Relationship1To1AllRelationships.java: public void testSetToNewFromMappedBySide() { Relationship1To1AllRelationships.java: public void testDeleteFromMappedBySide() { Relationship1To1NoRelationships.java: public void testSetToExistingFromMappedBySide() { Relationship1To1NoRelationships.java: public void testSetToNewFromMappedBySide() { Relationship1ToManyAllRelationships.java: public void testAddExistingFromMappedbySide() { Relationship1ToManyAllRelationships.java: public void testReplaceFromMappedbySide() { Relationship1ToManyAllRelationships.java: public void testAddNewFromMappedbySide() { Relationship1ToManyAllRelationships.java: public void testSetToNullFromMappedbySide() { Relationship1ToManyAllRelationships.java: public void testRemoveFromMappedbySide() { Relationship1ToManyAllRelationships.java: public void testDeleteFromMappedbySide() { Relationship1ToManyNoRelationships.java: public void testAddExistingFromMappedbySide() { Relationship1ToManyNoRelationships.java: public void testSetToNewFromMappedbySide() { RelationshipManyToManyAllRelationships.java: public void testSetToNullFromMappedbySide() { RelationshipManyToManyAllRelationships.java: public void testReplaceFromMappedbySide() { RelationshipManyToManyAllRelationships.java: public void testAddNewFromMappedbySide() { RelationshipManyToManyAllRelationships.java: public void testAddExistingFromMappedbySide() { RelationshipManyToManyAllRelationships.java: public void testRemoveFromMappedbySide() { RelationshipManyToManyAllRelationships.java: public void testDeleteFromMappedbySide() { RelationshipManyToManyNoRelationships.java: public void testAddFromMappedbySide() { RelationshipManyToManyNoRelationships.java: public void testReplaceFromMappedbySide() { RelationshipNegative1To1Test.java: public void testA2BbutNotB2AMappedBy() { RelationshipNegative1To1Test.java: public void testSetOtherSideToNullMappedBy() { Please let us know if an important test case is missing. -- Michelle Joerg von Frantzius wrote: > Hi, > > when looking at the relationship tests in org.apache.jdo.tck.mapping, > it seems that the tests for bidirectional integrity only test changing > relationships from the "mapped-by" side of the relationship? That's my > impression at least from looking at the method names e.g. in > Relationship1ToManyAllRelationships.java. > > I'm asking this because I believe to see inconsistencies with > bidirectional relationships in the RI. > > Regards, > Jörg > |
|
|
Re: Bidirectional relationship tests in the TCKHI Jörg,
On May 27, 2008, at 9:51 AM, Joerg von Frantzius wrote: > Hi, > > when looking at the relationship tests in > org.apache.jdo.tck.mapping, it seems that the tests for > bidirectional integrity only test changing relationships from the > "mapped-by" side of the relationship? That's my impression at least > from looking at the method names e.g. in > Relationship1ToManyAllRelationships.java. There are a few relationship tests, and the intent was (is) to test changing relationships from both sides. If you can't find what you're looking for (in all the tests) please let us know. Craig > > > I'm asking this because I believe to see inconsistencies with > bidirectional relationships in the RI. > > Regards, > Jörg > > -- > ____________________________________________________________________ > artnology GmbH - Milastraße 4 - 10437 Berlin - Germany > Geschäftsführer: Ekkehard Blome (CEO), Felix Kuschnick (CCO) > Registergericht: Amtsgericht Berlin Charlottenburg HRB 76376 UST-Id. > DE 217652550 > Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:Craig.Russell@... P.S. A good JDO? O, Gasp! |
|
|
Re: Bidirectional relationship tests in the TCKSorry for not having had any time to look into this more thoroughly yet.
I'll hopefully find it next week. I think I experienced problems with changing bidirectional relationships on detached objects. Now I'm not sure whether the spec intended those to be managed as well? Craig L Russell schrieb: > HI Jörg, > > On May 27, 2008, at 9:51 AM, Joerg von Frantzius wrote: > >> Hi, >> >> when looking at the relationship tests in org.apache.jdo.tck.mapping, >> it seems that the tests for bidirectional integrity only test >> changing relationships from the "mapped-by" side of the relationship? >> That's my impression at least from looking at the method names e.g. >> in Relationship1ToManyAllRelationships.java. > > There are a few relationship tests, and the intent was (is) to test > changing relationships from both sides. > > If you can't find what you're looking for (in all the tests) please > let us know. > > Craig >> >> >> I'm asking this because I believe to see inconsistencies with >> bidirectional relationships in the RI. >> >> Regards, >> Jörg >> >> -- >> ____________________________________________________________________ >> artnology GmbH - Milastraße 4 - 10437 Berlin - Germany >> Geschäftsführer: Ekkehard Blome (CEO), Felix Kuschnick (CCO) >> Registergericht: Amtsgericht Berlin Charlottenburg HRB 76376 UST-Id. >> DE 217652550 >> > > Craig Russell > Architect, Sun Java Enterprise System http://java.sun.com/products/jdo > 408 276-5638 mailto:Craig.Russell@... > P.S. A good JDO? O, Gasp! > -- ____________________________________________________________________ artnology GmbH - Milastraße 4 - 10437 Berlin - Germany Geschäftsführer: Ekkehard Blome (CEO), Felix Kuschnick (CCO) Registergericht: Amtsgericht Berlin Charlottenburg HRB 76376 UST-Id. DE 217652550 |
|
|
Re: Bidirectional relationship tests in the TCKHi Jörg,
On Jun 6, 2008, at 10:30 AM, Joerg von Frantzius wrote: > Sorry for not having had any time to look into this more thoroughly > yet. I'll hopefully find it next week. > > I think I experienced problems with changing bidirectional > relationships on detached objects. Now I'm not sure whether the spec > intended those to be managed as well? Sure, any change to a persistent field of a detached object 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 to the TCK. Craig > > > Craig L Russell schrieb: >> HI Jörg, >> >> On May 27, 2008, at 9:51 AM, Joerg von Frantzius wrote: >> >>> Hi, >>> >>> when looking at the relationship tests in >>> org.apache.jdo.tck.mapping, it seems that the tests for >>> bidirectional integrity only test changing relationships from the >>> "mapped-by" side of the relationship? That's my impression at >>> least from looking at the method names e.g. in >>> Relationship1ToManyAllRelationships.java. >> >> There are a few relationship tests, and the intent was (is) to test >> changing relationships from both sides. >> >> If you can't find what you're looking for (in all the tests) please >> let us know. >> >> Craig >>> >>> >>> I'm asking this because I believe to see inconsistencies with >>> bidirectional relationships in the RI. >>> >>> Regards, >>> Jörg >>> >>> -- >>> ____________________________________________________________________ >>> artnology GmbH - Milastraße 4 - 10437 Berlin - Germany >>> Geschäftsführer: Ekkehard Blome (CEO), Felix Kuschnick (CCO) >>> Registergericht: Amtsgericht Berlin Charlottenburg HRB 76376 UST- >>> Id. DE 217652550 >>> >> >> Craig Russell >> Architect, Sun Java Enterprise System http://java.sun.com/products/ >> jdo >> 408 276-5638 mailto:Craig.Russell@... >> P.S. A good JDO? O, Gasp! >> > > > -- > ____________________________________________________________________ > artnology GmbH - Milastraße 4 - 10437 Berlin - Germany > Geschäftsführer: Ekkehard Blome (CEO), Felix Kuschnick (CCO) > Registergericht: Amtsgericht Berlin Charlottenburg HRB 76376 UST-Id. > DE 217652550 > Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:Craig.Russell@... P.S. A good JDO? O, Gasp! |
|
|
Re: Bidirectional relationship tests in the TCKHello Craig,
what I really meant was: when modifying state of bidirectional associations on detached objects, should those detached objects immediately reflect consistent bidirectional state in the VM even before attaching? E.g. set a one-to-one association from one side, and immediately see the newly associated object from the other side. "15.3 Relationship Mapping" says that "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 and will update the memory model for consistency." There is no flush when modifying detached objects, so this doesn't really sound like the memory model should get updated before the detached objects are attached again and a flush actually happens. From an application programmer's point of view, it would of course be desirable if behaviour was consistent both in attached and detached state. Regards, Jörg Craig L Russell schrieb: > Hi Jörg, > > On Jun 6, 2008, at 10:30 AM, Joerg von Frantzius wrote: > >> Sorry for not having had any time to look into this more thoroughly >> yet. I'll hopefully find it next week. >> >> I think I experienced problems with changing bidirectional >> relationships on detached objects. Now I'm not sure whether the spec >> intended those to be managed as well? > > Sure, any change to a persistent field of a detached object 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 to > the TCK. > > Craig >> >> >> Craig L Russell schrieb: >>> HI Jörg, >>> >>> On May 27, 2008, at 9:51 AM, Joerg von Frantzius wrote: >>> >>>> Hi, >>>> >>>> when looking at the relationship tests in >>>> org.apache.jdo.tck.mapping, it seems that the tests for >>>> bidirectional integrity only test changing relationships from the >>>> "mapped-by" side of the relationship? That's my impression at least >>>> from looking at the method names e.g. in >>>> Relationship1ToManyAllRelationships.java. >>> >>> There are a few relationship tests, and the intent was (is) to test >>> changing relationships from both sides. >>> >>> If you can't find what you're looking for (in all the tests) please >>> let us know. >>> >>> Craig >>>> >>>> >>>> I'm asking this because I believe to see inconsistencies with >>>> bidirectional relationships in the RI. >>>> >>>> Regards, >>>> Jörg >>>> >>>> -- >>>> ____________________________________________________________________ >>>> artnology GmbH - Milastraße 4 - 10437 Berlin - Germany >>>> Geschäftsführer: Ekkehard Blome (CEO), Felix Kuschnick (CCO) >>>> Registergericht: Amtsgericht Berlin Charlottenburg HRB 76376 >>>> UST-Id. DE 217652550 >>>> >>> >>> Craig Russell >>> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo >>> 408 276-5638 mailto:Craig.Russell@... >>> P.S. A good JDO? O, Gasp! >>> >> >> >> -- >> ____________________________________________________________________ >> artnology GmbH - Milastraße 4 - 10437 Berlin - Germany >> Geschäftsführer: Ekkehard Blome (CEO), Felix Kuschnick (CCO) >> Registergericht: Amtsgericht Berlin Charlottenburg HRB 76376 UST-Id. >> DE 217652550 >> > > Craig Russell > Architect, Sun Java Enterprise System http://java.sun.com/products/jdo > 408 276-5638 mailto:Craig.Russell@... > P.S. A good JDO? O, Gasp! > -- ____________________________________________________________________ artnology GmbH - Milastraße 4 - 10437 Berlin - Germany Geschäftsführer: Ekkehard Blome (CEO), Felix Kuschnick (CCO) Registergericht: Amtsgericht Berlin Charlottenburg HRB 76376 UST-Id. DE 217652550 |
|
|
Re: Bidirectional relationship tests in the TCKHi Jörg,
On Jun 9, 2008, at 1:43 AM, Joerg von Frantzius wrote: > Hello Craig, > > what I really meant was: when modifying state of bidirectional > associations on detached objects, should those detached objects > immediately reflect consistent bidirectional state in the VM even > before attaching? E.g. set a one-to-one association from one side, > and immediately see the newly associated object from the other side. Well, no. Detached objects are not associated with a PersistenceManager and so flush() or commit() cannot by definition be applied to them. So there is no specified behavior that applies to relationships of detached objects. > > "15.3 Relationship Mapping" says that "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 and will update the memory model for consistency." > > There is no flush when modifying detached objects, so this doesn't > really sound like the memory model should get updated before the > detached objects are attached again and a flush actually happens. > From an application programmer's point of view, it would of course > be desirable if behaviour was consistent both in attached and > detached state. occurs, regardless of where the changes were made (attached or detached). Once the detached object is brought into the domain of a PersistenceManager via makePersistent, the flush and commit behavior applies. Regards, Craig > > > Regards, > Jörg > > Craig L Russell schrieb: >> Hi Jörg, >> >> On Jun 6, 2008, at 10:30 AM, Joerg von Frantzius wrote: >> >>> Sorry for not having had any time to look into this more >>> thoroughly yet. I'll hopefully find it next week. >>> >>> I think I experienced problems with changing bidirectional >>> relationships on detached objects. Now I'm not sure whether the >>> spec intended those to be managed as well? >> >> Sure, any change to a persistent field of a detached object 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 >> to the TCK. >> >> Craig >>> >>> >>> Craig L Russell schrieb: >>>> HI Jörg, >>>> >>>> On May 27, 2008, at 9:51 AM, Joerg von Frantzius wrote: >>>> >>>>> Hi, >>>>> >>>>> when looking at the relationship tests in >>>>> org.apache.jdo.tck.mapping, it seems that the tests for >>>>> bidirectional integrity only test changing relationships from >>>>> the "mapped-by" side of the relationship? That's my impression >>>>> at least from looking at the method names e.g. in >>>>> Relationship1ToManyAllRelationships.java. >>>> >>>> There are a few relationship tests, and the intent was (is) to >>>> test changing relationships from both sides. >>>> >>>> If you can't find what you're looking for (in all the tests) >>>> please let us know. >>>> >>>> Craig >>>>> >>>>> >>>>> I'm asking this because I believe to see inconsistencies with >>>>> bidirectional relationships in the RI. >>>>> >>>>> Regards, >>>>> Jörg >>>>> >>>>> -- >>>>> ____________________________________________________________________ >>>>> artnology GmbH - Milastraße 4 - 10437 Berlin - Germany >>>>> Geschäftsführer: Ekkehard Blome (CEO), Felix Kuschnick (CCO) >>>>> Registergericht: Amtsgericht Berlin Charlottenburg HRB 76376 UST- >>>>> Id. DE 217652550 >>>>> >>>> >>>> Craig Russell >>>> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo >>>> 408 276-5638 mailto:Craig.Russell@... >>>> P.S. A good JDO? O, Gasp! >>>> >>> >>> >>> -- >>> ____________________________________________________________________ >>> artnology GmbH - Milastraße 4 - 10437 Berlin - Germany >>> Geschäftsführer: Ekkehard Blome (CEO), Felix Kuschnick (CCO) >>> Registergericht: Amtsgericht Berlin Charlottenburg HRB 76376 UST- >>> Id. DE 217652550 >>> >> >> Craig Russell >> Architect, Sun Java Enterprise System http://java.sun.com/products/ >> jdo >> 408 276-5638 mailto:Craig.Russell@... >> P.S. A good JDO? O, Gasp! >> > > > -- > ____________________________________________________________________ > artnology GmbH - Milastraße 4 - 10437 Berlin - Germany > Geschäftsführer: Ekkehard Blome (CEO), Felix Kuschnick (CCO) > Registergericht: Amtsgericht Berlin Charlottenburg HRB 76376 UST-Id. > DE 217652550 > Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:Craig.Russell@... P.S. A good JDO? O, Gasp! |
|
|
Re: Bidirectional relationship tests in the TCKCraig L Russell schrieb:
> Hi Jörg, > > On Jun 9, 2008, at 1:43 AM, Joerg von Frantzius wrote: > >> Hello Craig, >> >> what I really meant was: when modifying state of bidirectional >> associations on detached objects, should those detached objects >> immediately reflect consistent bidirectional state in the VM even >> before attaching? E.g. set a one-to-one association from one side, >> and immediately see the newly associated object from the other side. > > Well, no. Detached objects are not associated with a > PersistenceManager and so flush() or commit() cannot by definition be > applied to them. So there is no specified behavior that applies to > relationships of detached objects. >> >> "15.3 Relationship Mapping" says that "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 and will update the memory model for consistency." >> >> There is no flush when modifying detached objects, so this doesn't >> really sound like the memory model should get updated before the >> detached objects are attached again and a flush actually happens. >> From an application programmer's point of view, it would of course be >> desirable if behaviour was consistent both in attached and detached >> state. > > It is consistent. If you flush or commit, all the specified behavior > occurs, regardless of where the changes were made (attached or detached). When I set an association and read it afterwards from the same side that I modified, I'll immediately see my changes without having to call flush() inbetween. So the behaviour for "seeing results of association modification" is depending on which side of the association I'm looking at. I wonder if that is really necessary? IMHO, it would be more consistent if an application programmer didn't have to think about which side of a bidirectional association (s)he is looking at. > > Once the detached object is brought into the domain of a > PersistenceManager via makePersistent, the flush and commit behavior > applies. > > Regards, > > Craig >> >> >> Regards, >> Jörg >> >> Craig L Russell schrieb: >>> Hi Jörg, >>> >>> On Jun 6, 2008, at 10:30 AM, Joerg von Frantzius wrote: >>> >>>> Sorry for not having had any time to look into this more thoroughly >>>> yet. I'll hopefully find it next week. >>>> >>>> I think I experienced problems with changing bidirectional >>>> relationships on detached objects. Now I'm not sure whether the >>>> spec intended those to be managed as well? >>> >>> Sure, any change to a persistent field of a detached object 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 to >>> the TCK. >>> >>> Craig >>>> >>>> >>>> Craig L Russell schrieb: >>>>> HI Jörg, >>>>> >>>>> On May 27, 2008, at 9:51 AM, Joerg von Frantzius wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> when looking at the relationship tests in >>>>>> org.apache.jdo.tck.mapping, it seems that the tests for >>>>>> bidirectional integrity only test changing relationships from the >>>>>> "mapped-by" side of the relationship? That's my impression at >>>>>> least from looking at the method names e.g. in >>>>>> Relationship1ToManyAllRelationships.java. >>>>> >>>>> There are a few relationship tests, and the intent was (is) to >>>>> test changing relationships from both sides. >>>>> >>>>> If you can't find what you're looking for (in all the tests) >>>>> please let us know. >>>>> >>>>> Craig >>>>>> >>>>>> >>>>>> I'm asking this because I believe to see inconsistencies with >>>>>> bidirectional relationships in the RI. >>>>>> >>>>>> Regards, >>>>>> Jörg >>>>>> >>>>>> -- >>>>>> ____________________________________________________________________ >>>>>> artnology GmbH - Milastraße 4 - 10437 Berlin - Germany >>>>>> Geschäftsführer: Ekkehard Blome (CEO), Felix Kuschnick (CCO) >>>>>> Registergericht: Amtsgericht Berlin Charlottenburg HRB 76376 >>>>>> UST-Id. DE 217652550 >>>>>> >>>>> >>>>> Craig Russell >>>>> Architect, Sun Java Enterprise System >>>>> http://java.sun.com/products/jdo >>>>> 408 276-5638 mailto:Craig.Russell@... >>>>> P.S. A good JDO? O, Gasp! >>>>> >>>> >>>> >>>> -- >>>> ____________________________________________________________________ >>>> artnology GmbH - Milastraße 4 - 10437 Berlin - Germany >>>> Geschäftsführer: Ekkehard Blome (CEO), Felix Kuschnick (CCO) >>>> Registergericht: Amtsgericht Berlin Charlottenburg HRB 76376 >>>> UST-Id. DE 217652550 >>>> >>> >>> Craig Russell >>> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo >>> 408 276-5638 mailto:Craig.Russell@... >>> P.S. A good JDO? O, Gasp! >>> >> >> >> -- >> ____________________________________________________________________ >> artnology GmbH - Milastraße 4 - 10437 Berlin - Germany >> Geschäftsführer: Ekkehard Blome (CEO), Felix Kuschnick (CCO) >> Registergericht: Amtsgericht Berlin Charlottenburg HRB 76376 UST-Id. >> DE 217652550 >> > > Craig Russell > Architect, Sun Java Enterprise System http://java.sun.com/products/jdo > 408 276-5638 mailto:Craig.Russell@... > P.S. A good JDO? O, Gasp! > -- ____________________________________________________________________ artnology GmbH - Milastraße 4 - 10437 Berlin - Germany Geschäftsführer: Ekkehard Blome (CEO), Felix Kuschnick (CCO) Registergericht: Amtsgericht Berlin Charlottenburg HRB 76376 UST-Id. DE 217652550 |
|
|
Re: Bidirectional relationship tests in the TCKHi Jörg,
On Jun 10, 2008, at 5:30 AM, Joerg von Frantzius wrote: > Craig L Russell schrieb: >> Hi Jörg, >> >> On Jun 9, 2008, at 1:43 AM, Joerg von Frantzius wrote: >> >>> Hello Craig, >>> >>> what I really meant was: when modifying state of bidirectional >>> associations on detached objects, should those detached objects >>> immediately reflect consistent bidirectional state in the VM even >>> before attaching? E.g. set a one-to-one association from one side, >>> and immediately see the newly associated object from the other side. >> >> Well, no. Detached objects are not associated with a >> PersistenceManager and so flush() or commit() cannot by definition >> be applied to them. So there is no specified behavior that applies >> to relationships of detached objects. >>> >>> "15.3 Relationship Mapping" says that "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 and will update the memory model for >>> consistency." >>> >>> There is no flush when modifying detached objects, so this doesn't >>> really sound like the memory model should get updated before the >>> detached objects are attached again and a flush actually happens. >>> From an application programmer's point of view, it would of course >>> be desirable if behaviour was consistent both in attached and >>> detached state. >> >> It is consistent. If you flush or commit, all the specified >> behavior occurs, regardless of where the changes were made >> (attached or detached). > That leads me to the question: why is the memory model to be updated > only after flush()? > > When I set an association and read it afterwards from the same side > that I modified, I'll immediately see my changes without having to > call flush() inbetween. So the behaviour for "seeing results of > association modification" is depending on which side of the > association I'm looking at. I wonder if that is really necessary? > IMHO, it would be more consistent if an application programmer > didn't have to think about which side of a bidirectional association > (s)he is looking at. updating the other side of a managed relationship. However, it's not 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 both sides of the relationship. So at flush (when the jdo implementation synchronizes the state of memory and datastore) both sides of the memory relationship must be consistent with the datastore artifact. Between beginning a transaction and flushing the changed state to the datastore, there is no other defined consistency point. From an application perspective, there is no point at which the application is done making changes that are supposed to be consistent. That is, consistency of the memory model may change during processing. If you're looking for consistency in memory, the application is free to implement whatever behavior is appropriate to ensure consistency, including modeling the relationship as a separate object and using methods to manage the relationship instances. But even then, there is time between setting one side of the relationship and setting the other side to be consistent. So the memory model always has a delay during which time the memory model is inconsistent. So it's a matter of defining the consistency point where both sides are supposed to be consistent with each other. In the case of jdo, there is a natural consistency point that we've used for other cases, such as construction of a new instance. We don't assume the newly constructed instance is self-consistent until flush. Regards, Craig > >> >> Once the detached object is brought into the domain of a >> PersistenceManager via makePersistent, the flush and commit >> behavior applies. >> >> Regards, >> >> Craig >>> >>> >>> Regards, >>> Jörg >>> >>> Craig L Russell schrieb: >>>> Hi Jörg, >>>> >>>> On Jun 6, 2008, at 10:30 AM, Joerg von Frantzius wrote: >>>> >>>>> Sorry for not having had any time to look into this more >>>>> thoroughly yet. I'll hopefully find it next week. >>>>> >>>>> I think I experienced problems with changing bidirectional >>>>> relationships on detached objects. Now I'm not sure whether the >>>>> spec intended those to be managed as well? >>>> >>>> Sure, any change to a persistent field of a detached object >>>> 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 >>>> to the TCK. >>>> >>>> Craig >>>>> >>>>> >>>>> Craig L Russell schrieb: >>>>>> HI Jörg, >>>>>> >>>>>> On May 27, 2008, at 9:51 AM, Joerg von Frantzius wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> when looking at the relationship tests in >>>>>>> org.apache.jdo.tck.mapping, it seems that the tests for >>>>>>> bidirectional integrity only test changing relationships from >>>>>>> the "mapped-by" side of the relationship? That's my impression >>>>>>> at least from looking at the method names e.g. in >>>>>>> Relationship1ToManyAllRelationships.java. >>>>>> >>>>>> There are a few relationship tests, and the intent was (is) to >>>>>> test changing relationships from both sides. >>>>>> >>>>>> If you can't find what you're looking for (in all the tests) >>>>>> please let us know. >>>>>> >>>>>> Craig >>>>>>> >>>>>>> >>>>>>> I'm asking this because I believe to see inconsistencies with >>>>>>> bidirectional relationships in the RI. >>>>>>> >>>>>>> Regards, >>>>>>> Jörg >>>>>>> >>>>>>> -- >>>>>>> ____________________________________________________________________ >>>>>>> artnology GmbH - Milastraße 4 - 10437 Berlin - Germany >>>>>>> Geschäftsführer: Ekkehard Blome (CEO), Felix Kuschnick (CCO) >>>>>>> Registergericht: Amtsgericht Berlin Charlottenburg HRB 76376 >>>>>>> UST-Id. DE 217652550 >>>>>>> >>>>>> >>>>>> Craig Russell >>>>>> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo >>>>>> 408 276-5638 mailto:Craig.Russell@... >>>>>> P.S. A good JDO? O, Gasp! >>>>>> >>>>> >>>>> >>>>> -- >>>>> ____________________________________________________________________ >>>>> artnology GmbH - Milastraße 4 - 10437 Berlin - Germany >>>>> Geschäftsführer: Ekkehard Blome (CEO), Felix Kuschnick (CCO) >>>>> Registergericht: Amtsgericht Berlin Charlottenburg HRB 76376 UST- >>>>> Id. DE 217652550 >>>>> >>>> >>>> Craig Russell >>>> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo >>>> 408 276-5638 mailto:Craig.Russell@... >>>> P.S. A good JDO? O, Gasp! >>>> >>> >>> >>> -- >>> ____________________________________________________________________ >>> artnology GmbH - Milastraße 4 - 10437 Berlin - Germany >>> Geschäftsführer: Ekkehard Blome (CEO), Felix Kuschnick (CCO) >>> Registergericht: Amtsgericht Berlin Charlottenburg HRB 76376 UST- >>> Id. DE 217652550 >>> >> >> Craig Russell >> Architect, Sun Java Enterprise System http://java.sun.com/products/ >> jdo >> 408 276-5638 mailto:Craig.Russell@... >> P.S. A good JDO? O, Gasp! >> > > > -- > ____________________________________________________________________ > artnology GmbH - Milastraße 4 - 10437 Berlin - Germany > Geschäftsführer: Ekkehard Blome (CEO), Felix Kuschnick (CCO) > Registergericht: Amtsgericht Berlin Charlottenburg HRB 76376 UST-Id. > DE 217652550 > Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:Craig.Russell@... P.S. A good JDO? O, Gasp! |
|
|
Re: Bidirectional relationship tests in the TCKHello Craig,
I see the point when operating in attached mode. Does it make sense to have immediate memory consistency when working with detached objects? Theoretically, all the information seems to be there to do it, but I'm not sure what implications this would have on the implementation (i.e. enhanced code and StateManager behaviour). Regards, Jörg Craig L Russell wrote: > Hi Jörg, > On Jun 10, 2008, at 5:30 AM, Joerg von Frantzius wrote: > >> Craig L Russell schrieb: >>> Hi Jörg, >>> >>> On Jun 9, 2008, at 1:43 AM, Joerg von Frantzius wrote: >>> >>>> Hello Craig, >>>> >>>> what I really meant was: when modifying state of bidirectional >>>> associations on detached objects, should those detached objects >>>> immediately reflect consistent bidirectional state in the VM even >>>> before attaching? E.g. set a one-to-one association from one side, >>>> and immediately see the newly associated object from the other side. >>> >>> Well, no. Detached objects are not associated with a >>> PersistenceManager and so flush() or commit() cannot by definition >>> be applied to them. So there is no specified behavior that applies >>> to relationships of detached objects. >>>> >>>> "15.3 Relationship Mapping" says that "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 and will update the memory model for consistency." >>>> >>>> There is no flush when modifying detached objects, so this doesn't >>>> really sound like the memory model should get updated before the >>>> detached objects are attached again and a flush actually happens. >>>> From an application programmer's point of view, it would of course >>>> be desirable if behaviour was consistent both in attached and >>>> detached state. >>> >>> It is consistent. If you flush or commit, all the specified behavior >>> occurs, regardless of where the changes were made (attached or >>> detached). >> That leads me to the question: why is the memory model to be updated >> only after flush()? >> >> When I set an association and read it afterwards from the same side >> that I modified, I'll immediately see my changes without having to >> call flush() inbetween. So the behaviour for "seeing results of >> association modification" is depending on which side of the >> association I'm looking at. I wonder if that is really necessary? >> IMHO, it would be more consistent if an application programmer didn't >> have to think about which side of a bidirectional association (s)he >> is looking at. > > Yes, you can make a case for the jdo implementation immediately > updating the other side of a managed relationship. However, it's not > 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 > both sides of the relationship. So at flush (when the jdo > implementation synchronizes the state of memory and datastore) both > sides of the memory relationship must be consistent with the datastore > artifact. > > Between beginning a transaction and flushing the changed state to the > datastore, there is no other defined consistency point. From an > application perspective, there is no point at which the application is > done making changes that are supposed to be consistent. That is, > consistency of the memory model may change during processing. > > If you're looking for consistency in memory, the application is free > to implement whatever behavior is appropriate to ensure consistency, > including modeling the relationship as a separate object and using > methods to manage the relationship instances. > > But even then, there is time between setting one side of the > relationship and setting the other side to be consistent. So the > memory model always has a delay during which time the memory model is > inconsistent. So it's a matter of defining the consistency point where > both sides are supposed to be consistent with each other. In the case > of jdo, there is a natural consistency point that we've used for other > cases, such as construction of a new instance. We don't assume the > newly constructed instance is self-consistent until flush. > > Regards, > > Craig >> >>> >>> Once the detached object is brought into the domain of a >>> PersistenceManager via makePersistent, the flush and commit behavior >>> applies. >>> >>> Regards, >>> >>> Craig >>>> >>>> >>>> Regards, >>>> Jörg >>>> >>>> Craig L Russell schrieb: >>>>> Hi Jörg, >>>>> >>>>> On Jun 6, 2008, at 10:30 AM, Joerg von Frantzius wrote: >>>>> >>>>>> Sorry for not having had any time to look into this more >>>>>> thoroughly yet. I'll hopefully find it next week. >>>>>> >>>>>> I think I experienced problems with changing bidirectional >>>>>> relationships on detached objects. Now I'm not sure whether the >>>>>> spec intended those to be managed as well? >>>>> >>>>> Sure, any change to a persistent field of a detached object 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 >>>>> to the TCK. >>>>> >>>>> Craig >>>>>> >>>>>> >>>>>> Craig L Russell schrieb: >>>>>>> HI Jörg, >>>>>>> >>>>>>> On May 27, 2008, at 9:51 AM, Joerg von Frantzius wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> when looking at the relationship tests in >>>>>>>> org.apache.jdo.tck.mapping, it seems that the tests for >>>>>>>> bidirectional integrity only test changing relationships from >>>>>>>> the "mapped-by" side of the relationship? That's my impression >>>>>>>> at least from looking at the method names e.g. in >>>>>>>> Relationship1ToManyAllRelationships.java. >>>>>>> >>>>>>> There are a few relationship tests, and the intent was (is) to >>>>>>> test changing relationships from both sides. >>>>>>> >>>>>>> If you can't find what you're looking for (in all the tests) >>>>>>> please let us know. >>>>>>> >>>>>>> Craig >>>>>>>> >>>>>>>> >>>>>>>> I'm asking this because I believe to see inconsistencies with >>>>>>>> bidirectional relationships in the RI. >>>>>>>> >>>>>>>> Regards, >>>>>>>> Jörg >>>>>>>> >>>>>>>> -- >>>>>>>> ____________________________________________________________________ >>>>>>>> >>>>>>>> artnology GmbH - Milastraße 4 - 10437 Berlin - Germany >>>>>>>> Geschäftsführer: Ekkehard Blome (CEO), Felix Kuschnick (CCO) >>>>>>>> Registergericht: Amtsgericht Berlin Charlottenburg HRB 76376 >>>>>>>> UST-Id. DE 217652550 >>>>>>>> >>>>>>> >>>>>>> Craig Russell >>>>>>> Architect, Sun Java Enterprise System >>>>>>> http://java.sun.com/products/jdo >>>>>>> 408 276-5638 mailto:Craig.Russell@... >>>>>>> P.S. A good JDO? O, Gasp! >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> ____________________________________________________________________ >>>>>> artnology GmbH - Milastraße 4 - 10437 Berlin - Germany >>>>>> Geschäftsführer: Ekkehard Blome (CEO), Felix Kuschnick (CCO) >>>>>> Registergericht: Amtsgericht Berlin Charlottenburg HRB 76376 >>>>>> UST-Id. DE 217652550 >>>>>> >>>>> >>>>> Craig Russell >>>>> Architect, Sun Java Enterprise System >>>>> http://java.sun.com/products/jdo >>>>> 408 276-5638 mailto:Craig.Russell@... >>>>> P.S. A good JDO? O, Gasp! >>>>> >>>> >>>> >>>> -- >>>> ____________________________________________________________________ >>>> artnology GmbH - Milastraße 4 - 10437 Berlin - Germany >>>> Geschäftsführer: Ekkehard Blome (CEO), Felix Kuschnick (CCO) >>>> Registergericht: Amtsgericht Berlin Charlottenburg HRB 76376 >>>> UST-Id. DE 217652550 >>>> >>> >>> Craig Russell >>> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo >>> 408 276-5638 mailto:Craig.Russell@... >>> P.S. A good JDO? O, Gasp! >>> >> >> >> -- >> ____________________________________________________________________ >> artnology GmbH - Milastraße 4 - 10437 Berlin - Germany >> Geschäftsführer: Ekkehard Blome (CEO), Felix Kuschnick (CCO) >> Registergericht: Amtsgericht Berlin Charlottenburg HRB 76376 UST-Id. >> DE 217652550 >> > > Craig L Russell > Architect, Sun Java Enterprise System http://java.sun.com/products/jdo > 408 276-5638 mailto:Craig.Russell@... > P.S. A good JDO? O, Gasp! > -- ____________________________________________________________________ artnology GmbH - Milastraße 4 - 10437 Berlin - Germany Geschäftsführer: Ekkehard Blome (CEO), Felix Kuschnick (CCO) Registergericht: Amtsgericht Berlin Charlottenburg HRB 76376 UST-Id. DE 217652550 |
|
|
Re: Bidirectional relationship tests in the TCKHi Jörg,
Since consistency is done explicitly at flush time, and there is no flush when operating with detached objects, I don't think there is an opportunity to synchronize to the datastore. The detachment model calls for the detached objects not to be managed, but instead simply to record changes. When detached objects are reattached to a PersistenceManager, then the behavior can again apply. Regards, Craig On Aug 11, 2008, at 3:01 AM, Joerg von Frantzius wrote: > Hello Craig, > > I see the point when operating in attached mode. Does it make sense > to have immediate memory consistency when working with detached > objects? Theoretically, all the information seems to be there to do > it, but I'm not sure what implications this would have on the > implementation (i.e. enhanced code and StateManager behaviour). > > Regards, > Jörg > > Craig L Russell wrote: >> Hi Jörg, >> On Jun 10, 2008, at 5:30 AM, Joerg von Frantzius wrote: >> >>> Craig L Russell schrieb: >>>> Hi Jörg, >>>> >>>> On Jun 9, 2008, at 1:43 AM, Joerg von Frantzius wrote: >>>> >>>>> Hello Craig, >>>>> >>>>> what I really meant was: when modifying state of bidirectional >>>>> associations on detached objects, should those detached objects >>>>> immediately reflect consistent bidirectional state in the VM >>>>> even before attaching? E.g. set a one-to-one association from >>>>> one side, and immediately see the newly associated object from >>>>> the other side. >>>> >>>> Well, no. Detached objects are not associated with a >>>> PersistenceManager and so flush() or commit() cannot by >>>> definition be applied to them. So there is no specified behavior >>>> that applies to relationships of detached objects. >>>>> >>>>> "15.3 Relationship Mapping" says that "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 and will update the memory model for >>>>> consistency." >>>>> >>>>> There is no flush when modifying detached objects, so this >>>>> doesn't really sound like the memory model should get updated >>>>> before the detached objects are attached again and a flush >>>>> actually happens. From an application programmer's point of >>>>> view, it would of course be desirable if behaviour was >>>>> consistent both in attached and detached state. >>>> >>>> It is consistent. If you flush or commit, all the specified >>>> behavior occurs, regardless of where the changes were made >>>> (attached or detached). >>> That leads me to the question: why is the memory model to be >>> updated only after flush()? >>> >>> When I set an association and read it afterwards from the same >>> side that I modified, I'll immediately see my changes without >>> having to call flush() inbetween. So the behaviour for "seeing >>> results of association modification" is depending on which side of >>> the association I'm looking at. I wonder if that is really >>> necessary? IMHO, it would be more consistent if an application >>> programmer didn't have to think about which side of a >>> bidirectional association (s)he is looking at. >> >> Yes, you can make a case for the jdo implementation immediately >> updating the other side of a managed relationship. However, it's >> not 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 both sides of the relationship. So at flush (when the >> jdo implementation synchronizes the state of memory and datastore) >> both sides of the memory relationship must be consistent with the >> datastore artifact. >> >> Between beginning a transaction and flushing the changed state to >> the datastore, there is no other defined consistency point. From an >> application perspective, there is no point at which the application >> is done making changes that are supposed to be consistent. That is, >> consistency of the memory model may change during processing. >> >> If you're looking for consistency in memory, the application is >> free to implement whatever behavior is appropriate to ensure >> consistency, including modeling the relationship as a separate >> object and using methods to manage the relationship instances. >> >> But even then, there is time between setting one side of the >> relationship and setting the other side to be consistent. So the >> memory model always has a delay during which time the memory model |