companyMapWithoutJoin.conf failiure: unexpected map SCO read from database
--------------------------------------------------------------------------

                 Key: JDO-439
                 URL: http://issues.apache.org/jira/browse/JDO-439
             Project: JDO
          Issue Type: Bug
          Components: tck20
    Affects Versions: JDO 2 final
            Reporter: Michael Bouschen
         Assigned To: Michael Bouschen
             Fix For: JDO 2 maintenance release 1


I see the configuration companyMapWithoutJoin.conf sporadically failing, 
because a map SCO read from the database does not have the expected value. Here 
is the test output from derby-dsid-companyWithoutJoin-junit.txt:

RUN CompletenessTestMap.test       FAILURE
Description: Completeness test with companyMapWithoutJoin model.
Time: 005
There was 1 failure:
1) 
test(org.apache.jdo.tck.mapping.CompletenessTestMap)junit.framework.AssertionFailedError:
 CompletenessTestMap failed; see list of failures below:
Expected this  instance:
    Company(1, name Sun Microsystems, Inc., founded 11/Apr/1952)
Got persistent instance:
    Company(1, name Sun Microsystems, Inc., founded 11/Apr/1952)
Detailed list of differences follows...
Context: Company<1>.departments[0]-> Department<1>.roles
Size mismatch: expected size= 3, original size= 2, current size= 2, counted 
size= 2
    expected '{role1=FullTimeEmployee(1, emp1Last, emp1First, born 10/Jun/1970, 
hired 1/Jan/1999, weeklyhours 40.0, $60000.0), role2=FullTimeEmployee(2, 
emp2Last, emp2First, born 22/Dez/1975, hired 1/Jul/2003, weeklyhours 40.0, 
$47000.0), role3=PartTimeEmployee(3, emp3Last, emp3First, born 5/Sep/1972, 
hired 15/Aug/2002, weeklyhours 19.0, $67.0)}'
      actual '{role1=FullTimeEmployee(1, emp1Last, emp1First, born 10/Jun/1970, 
hired 1/Jan/1999, weeklyhours 40.0, $60000.0),role3=PartTimeEmployee(3, 
emp3Last, emp3First, born 5/Sep/1972, hired 15/Aug/2002, weeklyhours 19.0, 
$67.0)}'

        at org.apache.jdo.tck.JDO_Test.fail(JDO_Test.java:638)
        at 
org.apache.jdo.tck.mapping.CompletenessTestMap.test(CompletenessTestMap.java:123)
        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:253)
        at 
org.apache.jdo.tck.util.BatchTestRunner.doRun(BatchTestRunner.java:107)
        at 
org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:147)
        at 
org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:122)
FAILURES!!!

The configuration uses a modified company model where Department has a map of 
employee instances and a new Employee field called role is the key in the map. 
The testdata provides a value for the role field in employee and for the key in 
the map. But the factory to create the instances does not populate the role 
field in employee. So there is an inconsistency between the key in the map (has 
a value) and the employee field (is null) used to map the key to the database. 
I enabled the JPOX RDBMS logger and saw that in the case of a failure there is 
an employee INSERT statement with NULL as the value for the ROLE column. When 
loading the corresponding department instance the map of employee misses this 
entry because the key is null.  The fix is easy: the factory needs to set the 
role field when creating the employee instance. 

Please note that this failure only happens sporadically, so I needed to run the 
test several time before I got the error above. In spide of the inconsistency 
between the map and the employee field, it is not clear to me why the test case 
shows different results on multiple runs. In most cases the test case succeeds 
(which means the key of the map is used as the value of th eemployee field), 
but sometimes it fails as shown above.  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to