JDO
  1. JDO
  2. JDO-521

Create tests for relationship mapping (spec section 15.3)

    Details

      Description

      We need a set of tests to test that an implementation syncs both sides of a relationship on flush().

      1. JDO-521.patch
        104 kB
        Michelle Caisse

        Activity

        Hide
        Michelle Caisse added a comment -

        Contains the first test class for managed relationships. There are three failures:

        RUN RelationshipSetFromNullTest.testSet1to1FromMappedSide FAILURE
        RUN RelationshipSetFromNullTest.testSet1to1FromMappedBySide FAILURE
        RUN RelationshipSetFromNullTest.testSet1toManyFromMappedSide FAILURE
        RUN RelationshipSetFromNullTest.testSet1toManyFromMappedbySide
        RUN RelationshipSetFromNullTest.testSetManytoManyFromMappedSide
        RUN RelationshipSetFromNullTest.testSetManytoMFromMappedbySide
        Description: Completeness test with standard mapping, basic testdata with no relationships.
        Time: 004
        There were 3 failures:
        1) testSet1to1FromMappedSide(org.apache.jdo.tck.mapping.RelationshipSetFromNullTest)junit.framework.AssertionFailedError:
        TestSet1to1FromMappedSide: Postcondition is false; other side of relationship not set on flush

        at org.apache.jdo.tck.JDO_Test.failOnError(JDO_Test.java:1103)
        at org.apache.jdo.tck.mapping.RelationshipSetFromNullTest.testSet1to1FromMappedSide(RelationshipSetFromNullTest.java:99)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:254)
        at org.apache.jdo.tck.util.BatchTestRunner.doRun(BatchTestRunner.java:108)
        at org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:148)
        at org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:123)
        2) testSet1to1FromMappedBySide(org.apache.jdo.tck.mapping.RelationshipSetFromNullTest)junit.framework.AssertionFailedError:
        testSet1to1FromMappedBySide: Postcondition is false; other side of relationship not set on flush

        at org.apache.jdo.tck.JDO_Test.failOnError(JDO_Test.java:1103)
        at org.apache.jdo.tck.mapping.RelationshipSetFromNullTest.testSet1to1FromMappedBySide(RelationshipSetFromNullTest.java:150)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:254)
        at org.apache.jdo.tck.util.BatchTestRunner.doRun(BatchTestRunner.java:108)
        at org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:148)
        at org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:123)
        3) testSet1toManyFromMappedSide(org.apache.jdo.tck.mapping.RelationshipSetFromNullTest)junit.framework.AssertionFailedError:
        testSet1toManyFromMappedSide: Postcondition is false; other side of relationship not set on flush
        testSet1toManyFromMappedSide: In new transaction, postcondition is false; other side of relationship is not set.

        at org.apache.jdo.tck.JDO_Test.failOnError(JDO_Test.java:1103)
        at org.apache.jdo.tck.mapping.RelationshipSetFromNullTest.testSet1toManyFromMappedSide(RelationshipSetFromNullTest.java:201)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:254)
        at org.apache.jdo.tck.util.BatchTestRunner.doRun(BatchTestRunner.java:108)
        at org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:148)
        at org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:123)

        Show
        Michelle Caisse added a comment - Contains the first test class for managed relationships. There are three failures: RUN RelationshipSetFromNullTest.testSet1to1FromMappedSide FAILURE RUN RelationshipSetFromNullTest.testSet1to1FromMappedBySide FAILURE RUN RelationshipSetFromNullTest.testSet1toManyFromMappedSide FAILURE RUN RelationshipSetFromNullTest.testSet1toManyFromMappedbySide RUN RelationshipSetFromNullTest.testSetManytoManyFromMappedSide RUN RelationshipSetFromNullTest.testSetManytoMFromMappedbySide Description: Completeness test with standard mapping, basic testdata with no relationships. Time: 004 There were 3 failures: 1) testSet1to1FromMappedSide(org.apache.jdo.tck.mapping.RelationshipSetFromNullTest)junit.framework.AssertionFailedError: TestSet1to1FromMappedSide: Postcondition is false; other side of relationship not set on flush at org.apache.jdo.tck.JDO_Test.failOnError(JDO_Test.java:1103) at org.apache.jdo.tck.mapping.RelationshipSetFromNullTest.testSet1to1FromMappedSide(RelationshipSetFromNullTest.java:99) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:254) at org.apache.jdo.tck.util.BatchTestRunner.doRun(BatchTestRunner.java:108) at org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:148) at org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:123) 2) testSet1to1FromMappedBySide(org.apache.jdo.tck.mapping.RelationshipSetFromNullTest)junit.framework.AssertionFailedError: testSet1to1FromMappedBySide: Postcondition is false; other side of relationship not set on flush at org.apache.jdo.tck.JDO_Test.failOnError(JDO_Test.java:1103) at org.apache.jdo.tck.mapping.RelationshipSetFromNullTest.testSet1to1FromMappedBySide(RelationshipSetFromNullTest.java:150) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:254) at org.apache.jdo.tck.util.BatchTestRunner.doRun(BatchTestRunner.java:108) at org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:148) at org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:123) 3) testSet1toManyFromMappedSide(org.apache.jdo.tck.mapping.RelationshipSetFromNullTest)junit.framework.AssertionFailedError: testSet1toManyFromMappedSide: Postcondition is false; other side of relationship not set on flush testSet1toManyFromMappedSide: In new transaction, postcondition is false; other side of relationship is not set. at org.apache.jdo.tck.JDO_Test.failOnError(JDO_Test.java:1103) at org.apache.jdo.tck.mapping.RelationshipSetFromNullTest.testSet1toManyFromMappedSide(RelationshipSetFromNullTest.java:201) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:254) at org.apache.jdo.tck.util.BatchTestRunner.doRun(BatchTestRunner.java:108) at org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:148) at org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:123)
        Hide
        Michelle Caisse added a comment -

        Minor cleanup

        Show
        Michelle Caisse added a comment - Minor cleanup
        Hide
        Michelle Caisse added a comment -

        Minor cleanup, grant license

        Show
        Michelle Caisse added a comment - Minor cleanup, grant license
        Hide
        Michelle Caisse added a comment -

        Minor fixes, added more tests.

        Show
        Michelle Caisse added a comment - Minor fixes, added more tests.
        Hide
        Craig L Russell added a comment -

        Here are all the negative tests that I came up with:
        Error conditions
        setting both sides of a one-to-one relationship such that they do not refer to each other
        a1 <-> b1 // pre-condition
        a2 <-> b2 // pre-condition
        a3 = new A() // pre-condition
        a1.setB(b2); b2.setA(a3); // error on flush
        setting one side of a one-to-one relationship and setting the other side to null
        a1 <-> b1 // pre-condition
        a2 <-> b2 // pre-condition
        a1.setB(b2); b2.setA(null); // error on flush
        setting one side of a one-to-many relationship and deleting the other side
        d1 <-> e1, e2 // pre-condition
        d2.add(e1); pm.deletePersistent(e1); // error on flush
        adding a related instance (with a single-valued mapped-by relationship field) to more than one one-to-many collection relationship
        e1 = new E();
        d1.add(e1); d2.add(e1); // error on flush
        adding a related instance to a collection and setting the other side to a different instance
        e1 = new E();
        d1.add(e1); e1.setD(d2); // error on flush
        adding a related instance to a collection and deleting the related instance
        d1 <-> e1, e2 // pre-condition
        d2.add(e1); pm.deletePersistent(e1); // error on flush

        Show
        Craig L Russell added a comment - Here are all the negative tests that I came up with: Error conditions setting both sides of a one-to-one relationship such that they do not refer to each other a1 <-> b1 // pre-condition a2 <-> b2 // pre-condition a3 = new A() // pre-condition a1.setB(b2); b2.setA(a3); // error on flush setting one side of a one-to-one relationship and setting the other side to null a1 <-> b1 // pre-condition a2 <-> b2 // pre-condition a1.setB(b2); b2.setA(null); // error on flush setting one side of a one-to-many relationship and deleting the other side d1 <-> e1, e2 // pre-condition d2.add(e1); pm.deletePersistent(e1); // error on flush adding a related instance (with a single-valued mapped-by relationship field) to more than one one-to-many collection relationship e1 = new E(); d1.add(e1); d2.add(e1); // error on flush adding a related instance to a collection and setting the other side to a different instance e1 = new E(); d1.add(e1); e1.setD(d2); // error on flush adding a related instance to a collection and deleting the related instance d1 <-> e1, e2 // pre-condition d2.add(e1); pm.deletePersistent(e1); // error on flush
        Hide
        Michelle Caisse added a comment -

        The third and sixth negative tests appear to be the same.

        Show
        Michelle Caisse added a comment - The third and sixth negative tests appear to be the same.
        Hide
        Michelle Caisse added a comment -

        Patch with new tests, old tests refactored. Complete pending comments.

        Show
        Michelle Caisse added a comment - Patch with new tests, old tests refactored. Complete pending comments.
        Hide
        Craig L Russell added a comment -

        In AbstractRelationshipTest,
        should probably promote method deferredAssertTrue to JDO_Test, and should probably promote field isTestToBePerformed to JDO_Test.

        In Relationship1To1NoRelationships, testSetToNewFromMappedSide and testSetToNewFromMappedBySide test for the "previous relationship (emp1) not nulled in new pm"); but there is no previous relationship (four places).

        [nit] the code dept1.getEmployees().contains((Object)emp1)) should not cast emp1 to Object; there's no harm but it doesn't do anything so it's a distraction.

        In Relationship1ToManyAllRelationships, testSetToExistingFromMappedSide
        + deferredAssertTrue(!dept1.getEmployees().contains(emp1),
        + ASSERTION_FAILED + testMethod,
        + "Postcondition is false; "
        + + "previous relationship (dept1) not nulled on flush");
        The comment is incorrect. Perhaps "reference emp1 not removed from previous relationship (dept1.employees)"

        In Relationship1ToManyAllRelationships, testAddExistingFromMappedbySide replaces the collection. We need a different test that instead of:
        + Set emps = new HashSet();
        + emps.add(emp4);
        + dept1.setEmployees(emps);
        + pm.flush();

        does:
        + Set emps = dept1.getEmployees();
        + emps.add(emp4);
        + pm.flush();

        The existing test testAddExistingFromMappedbySide should change as above, and add new tests:
        testReplaceFromMappedBySide that does as above, creates a new HashSet and replaces the existing collection
        testAddNewFromMappedBySide that adds a new Employee to the existing collection

        General suggestion on the test naming: Add should add to an existing collection; Remove should remove from an existing collection; Replace should replace an existing collection (or null collection); SetNull should replace an existing collection with null.

        In RelationshipManyToManyAllRelationships, need a tests testAddExistingFromMappedSide, testAddNewFromMappedSide, testAddExistingFromMappedBySide, testAddNewFromMappedBySide. Instead of replacing the collection, these tests would use the existing collection and add a new Employee or Project or add an existing Employee or Project.

        In RelationshipManyToManyNoRelationships the comments on test naming also apply.
        Is testAddExistingMFromMappedbySide a typo?

        In RelationshipNegative1ToManyTest, testAddToMoreThanOne appears to be a copy of another test, including javadoc.
        testAddToMoreThanOne has the wrong javadoc.

        Show
        Craig L Russell added a comment - In AbstractRelationshipTest, should probably promote method deferredAssertTrue to JDO_Test, and should probably promote field isTestToBePerformed to JDO_Test. In Relationship1To1NoRelationships, testSetToNewFromMappedSide and testSetToNewFromMappedBySide test for the "previous relationship (emp1) not nulled in new pm"); but there is no previous relationship (four places). [nit] the code dept1.getEmployees().contains((Object)emp1)) should not cast emp1 to Object; there's no harm but it doesn't do anything so it's a distraction. In Relationship1ToManyAllRelationships, testSetToExistingFromMappedSide + deferredAssertTrue(!dept1.getEmployees().contains(emp1), + ASSERTION_FAILED + testMethod, + "Postcondition is false; " + + "previous relationship (dept1) not nulled on flush"); The comment is incorrect. Perhaps "reference emp1 not removed from previous relationship (dept1.employees)" In Relationship1ToManyAllRelationships, testAddExistingFromMappedbySide replaces the collection. We need a different test that instead of: + Set emps = new HashSet(); + emps.add(emp4); + dept1.setEmployees(emps); + pm.flush(); does: + Set emps = dept1.getEmployees(); + emps.add(emp4); + pm.flush(); The existing test testAddExistingFromMappedbySide should change as above, and add new tests: testReplaceFromMappedBySide that does as above, creates a new HashSet and replaces the existing collection testAddNewFromMappedBySide that adds a new Employee to the existing collection General suggestion on the test naming: Add should add to an existing collection; Remove should remove from an existing collection; Replace should replace an existing collection (or null collection); SetNull should replace an existing collection with null. In RelationshipManyToManyAllRelationships, need a tests testAddExistingFromMappedSide, testAddNewFromMappedSide, testAddExistingFromMappedBySide, testAddNewFromMappedBySide. Instead of replacing the collection, these tests would use the existing collection and add a new Employee or Project or add an existing Employee or Project. In RelationshipManyToManyNoRelationships the comments on test naming also apply. Is testAddExistingMFromMappedbySide a typo? In RelationshipNegative1ToManyTest, testAddToMoreThanOne appears to be a copy of another test, including javadoc. testAddToMoreThanOne has the wrong javadoc.
        Hide
        Craig L Russell added a comment -

        I apologize for not reviewing the test specification very well; many of my comments would have been resolved before creating the test cases.

        Craig

        Show
        Craig L Russell added a comment - I apologize for not reviewing the test specification very well; many of my comments would have been resolved before creating the test cases. Craig
        Hide
        Michelle Caisse added a comment -

        No problem. I appreciate the comments.

        Thanks,
        Michelle

        Show
        Michelle Caisse added a comment - No problem. I appreciate the comments. Thanks, Michelle
        Hide
        Michelle Caisse added a comment -

        Made changes suggested in review.

        Show
        Michelle Caisse added a comment - Made changes suggested in review.
        Hide
        Andy Jefferson added a comment -

        The "negative" 1-1 relation tests raise a question. Let's take the first one. You have an already persistent Employee, and an already persistent MedicalInsurance. You then persist a new Employee. Ok, no problem with that. You then call
        emp1.setMedicalInsurance(medIns2);
        The spec says "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"
        but that doesn't by my reading prohibit updating the in memory model, and so for any implementation that does update in-memory on each change these "negative" tests will fail since they don't allow for it. Or is it that there is some requirement to prohibit this ? An implementation can flush changes to the datastore without user-called flush() or commit() (unless using optimistic txns).

        PS. Any chance the test "conf" files can be called "managedRelations.conf" or something ? "relationshipsNoRelationships.conf" leaves me baffled ... since if it is for relationships and has no relationships?? surely it would have to have some relationships to test managed relationships ? Maybe I'm missing some secret naming schema

        Show
        Andy Jefferson added a comment - The "negative" 1-1 relation tests raise a question. Let's take the first one. You have an already persistent Employee, and an already persistent MedicalInsurance. You then persist a new Employee. Ok, no problem with that. You then call emp1.setMedicalInsurance(medIns2); The spec says "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" but that doesn't by my reading prohibit updating the in memory model, and so for any implementation that does update in-memory on each change these "negative" tests will fail since they don't allow for it. Or is it that there is some requirement to prohibit this ? An implementation can flush changes to the datastore without user-called flush() or commit() (unless using optimistic txns). PS. Any chance the test "conf" files can be called "managedRelations.conf" or something ? "relationshipsNoRelationships.conf" leaves me baffled ... since if it is for relationships and has no relationships?? surely it would have to have some relationships to test managed relationships ? Maybe I'm missing some secret naming schema
        Hide
        Andy Jefferson added a comment -

        The negative test I was expecting to find was where you set up something like this

        Employee emp1 = new FullTimeEmployee();
        MedicalInsurance ins1 = new MedicalInsurance();
        Employee emp2 = new PartTimeEmployee();
        emp1.setMedicalInsurance(ins1);
        ins1.setEmployee(emp2);
        pm.makePersistent(emp1);

        so in a single user operation inconsistent data is provided (hence independent of when data is flushed to the datastore) hence an expected JDOUserException. Does this exist ?

        Show
        Andy Jefferson added a comment - The negative test I was expecting to find was where you set up something like this Employee emp1 = new FullTimeEmployee(); MedicalInsurance ins1 = new MedicalInsurance(); Employee emp2 = new PartTimeEmployee(); emp1.setMedicalInsurance(ins1); ins1.setEmployee(emp2); pm.makePersistent(emp1); so in a single user operation inconsistent data is provided (hence independent of when data is flushed to the datastore) hence an expected JDOUserException. Does this exist ?
        Hide
        Craig L Russell added a comment -

        > The spec says "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" but that doesn't by my reading prohibit updating the in memory model, and so for any implementation that does update in-memory on each change these "negative" tests will fail since they don't allow for it. Or is it that there is some requirement to prohibit this ? An implementation can flush changes to the datastore without user-called flush() or commit() (unless using optimistic txns).

        From the spec, "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"

        If you update both sides immediately, when would there ever be a conflicting change?

        Show
        Craig L Russell added a comment - > The spec says "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" but that doesn't by my reading prohibit updating the in memory model, and so for any implementation that does update in-memory on each change these "negative" tests will fail since they don't allow for it. Or is it that there is some requirement to prohibit this ? An implementation can flush changes to the datastore without user-called flush() or commit() (unless using optimistic txns). From the spec, "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" If you update both sides immediately, when would there ever be a conflicting change?
        Hide
        Craig L Russell added a comment -

        > PS. Any chance the test "conf" files can be called "managedRelations.conf" or something ? "relationshipsNoRelationships.conf" leaves me baffled ... since if it is for relationships and has no relationships?? surely it would have to have some relationships to test managed relationships ? Maybe I'm missing some secret naming schema

        The naming scheme for the conf files is supposed to reflect both the type of test "relationship" and the test data "NoRelationships". The naming is supposed to be "easy to use" so if you can suggest different names, they can certainly be changed.

        Show
        Craig L Russell added a comment - > PS. Any chance the test "conf" files can be called "managedRelations.conf" or something ? "relationshipsNoRelationships.conf" leaves me baffled ... since if it is for relationships and has no relationships?? surely it would have to have some relationships to test managed relationships ? Maybe I'm missing some secret naming schema The naming scheme for the conf files is supposed to reflect both the type of test "relationship" and the test data "NoRelationships". The naming is supposed to be "easy to use" so if you can suggest different names, they can certainly be changed.
        Hide
        Craig L Russell added a comment -

        > If you update both sides immediately, when would there ever be a conflicting change?

        I was responding in chronological order to the comments. Andy, in your view the only conflicting changes are in persisting an inconsistent object graph?

        Show
        Craig L Russell added a comment - > If you update both sides immediately, when would there ever be a conflicting change? I was responding in chronological order to the comments. Andy, in your view the only conflicting changes are in persisting an inconsistent object graph?
        Hide
        Craig L Russell added a comment -

        The reason that conflicting changes aren't portable is that depending on the order of operations, different results would obtain. For example, in the negative test scenario,

        + pm.makePersistent(medInsNew);
        + medIns2.setEmployee(emp1);
        + emp1.setMedicalInsurance(medInsNew);
        + doFlush(testMethod);

        If you reverse the order of operations,

        + pm.makePersistent(medInsNew);
        + emp1.setMedicalInsurance(medInsNew);
        + medIns2.setEmployee(emp1);
        + doFlush(testMethod);

        If you allow these two sequences to be valid and result in different changes to the datastore, I think there is a problem.

        Show
        Craig L Russell added a comment - The reason that conflicting changes aren't portable is that depending on the order of operations, different results would obtain. For example, in the negative test scenario, + pm.makePersistent(medInsNew); + medIns2.setEmployee(emp1); + emp1.setMedicalInsurance(medInsNew); + doFlush(testMethod); If you reverse the order of operations, + pm.makePersistent(medInsNew); + emp1.setMedicalInsurance(medInsNew); + medIns2.setEmployee(emp1); + doFlush(testMethod); If you allow these two sequences to be valid and result in different changes to the datastore, I think there is a problem.
        Hide
        Michelle Caisse added a comment -

        Negative tests still fail:

        RUN RelationshipNegative1To1Test.testA2BbutNotB2AMapped FAILURE
        RUN RelationshipNegative1To1Test.testA2BbutNotB2AMappedBy FAILURE
        RUN RelationshipNegative1To1Test.testSetOtherSideToNullMapped FAILURE
        RUN RelationshipNegative1To1Test.testSetOtherSideToNullMappedBy FAILURE
        RUN RelationshipNegative1ToManyTest.testDeleteOtherSide FAILURE
        RUN RelationshipNegative1ToManyTest.testAddToMoreThanOne FAILURE
        RUN RelationshipNegative1ToManyTest.testAInBbutNotB2A FAILURE
        Description: Managed relationship tests with standard mapping, basic testdata with no relationships.
        Time: 016
        There were 7 failures:
        testA2BbutNotB2AMapped(org.apache.jdo.tck.mapping.RelationshipNegative1To1Test)junit.framework.AssertionFailedError: Assertion A15-3.1 (RelationshipNegative1To1Test) failed: testA2BbutNotB2AMapped: expected JDOUserException on flush!
        at org.apache.jdo.tck.mapping.RelationshipNegative1To1Test.doFlush(RelationshipNegative1To1Test.java:147)
        at org.apache.jdo.tck.mapping.RelationshipNegative1To1Test.testA2BbutNotB2AMapped(RelationshipNegative1To1Test.java:98)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:254)
        at org.apache.jdo.tck.util.BatchTestRunner.doRun(BatchTestRunner.java:108)
        at org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:148)
        at org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:123)
        ...

        Show
        Michelle Caisse added a comment - Negative tests still fail: RUN RelationshipNegative1To1Test.testA2BbutNotB2AMapped FAILURE RUN RelationshipNegative1To1Test.testA2BbutNotB2AMappedBy FAILURE RUN RelationshipNegative1To1Test.testSetOtherSideToNullMapped FAILURE RUN RelationshipNegative1To1Test.testSetOtherSideToNullMappedBy FAILURE RUN RelationshipNegative1ToManyTest.testDeleteOtherSide FAILURE RUN RelationshipNegative1ToManyTest.testAddToMoreThanOne FAILURE RUN RelationshipNegative1ToManyTest.testAInBbutNotB2A FAILURE Description: Managed relationship tests with standard mapping, basic testdata with no relationships. Time: 016 There were 7 failures: testA2BbutNotB2AMapped(org.apache.jdo.tck.mapping.RelationshipNegative1To1Test)junit.framework.AssertionFailedError: Assertion A15-3.1 (RelationshipNegative1To1Test) failed: testA2BbutNotB2AMapped: expected JDOUserException on flush! at org.apache.jdo.tck.mapping.RelationshipNegative1To1Test.doFlush(RelationshipNegative1To1Test.java:147) at org.apache.jdo.tck.mapping.RelationshipNegative1To1Test.testA2BbutNotB2AMapped(RelationshipNegative1To1Test.java:98) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:254) at org.apache.jdo.tck.util.BatchTestRunner.doRun(BatchTestRunner.java:108) at org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:148) at org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:123) ...
        Hide
        Andy Jefferson added a comment -

        In file src/java/org/apache/jdo/tck/mapping/RelationshipNegative1To1Test.java the tests
        "testSetOtherSideToNullMappedBy", "testSetOtherSideToNullMapped" are badly defined.
        By this I mean you have objects "emp1", "emp2", "medIns1", "medIns2" that have no relations after setUp(). In the test you then rely on
        medIns2.setEmployee(null); or emp1.setMedicalInsurance(null);
        and expect the implementation to interpret this as "the relation has been changed at this other side to something inconsistent". But it was null before those setter calls and is still null and so the implementation is entitled to ignore the setter call as not changing anything. Perhaps if the tests were changed to have a relation first, and then nulling it out that would be reasonably interpreted as an inconsistent update.

        Show
        Andy Jefferson added a comment - In file src/java/org/apache/jdo/tck/mapping/RelationshipNegative1To1Test.java the tests "testSetOtherSideToNullMappedBy", "testSetOtherSideToNullMapped" are badly defined. By this I mean you have objects "emp1", "emp2", "medIns1", "medIns2" that have no relations after setUp(). In the test you then rely on medIns2.setEmployee(null); or emp1.setMedicalInsurance(null); and expect the implementation to interpret this as "the relation has been changed at this other side to something inconsistent". But it was null before those setter calls and is still null and so the implementation is entitled to ignore the setter call as not changing anything. Perhaps if the tests were changed to have a relation first, and then nulling it out that would be reasonably interpreted as an inconsistent update.
        Hide
        Michelle Caisse added a comment -

        I've moved RelationshipNegative1To1Test to relationshipAllRelationships.conf so that the instances get initialized with relationships. All tests in this class now pass. Revision: 599209

        Show
        Michelle Caisse added a comment - I've moved RelationshipNegative1To1Test to relationshipAllRelationships.conf so that the instances get initialized with relationships. All tests in this class now pass. Revision: 599209
        Hide
        Andy Jefferson added a comment -

        All managed relations tests pass with JPOX SVN trunk

        Show
        Andy Jefferson added a comment - All managed relations tests pass with JPOX SVN trunk

          People

          • Assignee:
            Andy Jefferson
            Reporter:
            Michelle Caisse
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development