|
Yes, we agree that the test should display values when the assertion fails. I have filed
The reporting problem has been solved. This test now gives, for both application and datastore identity:
test(org.apache.jdo.tck.models.fieldtypes.TestCollectionCollections)junit.framework.AssertionFailedError: Assertion A6.4.3-33 (TestCollectionCollections) failed: Expected and observed do not match!! For element 12, expected = [Wed Dec 31 16:33:27 PST 1969, Thu Jan 01 16:44:27 PST 1970, Sat Jan 10 23:24:33 PST 1970, Sat Jan 10 23:24:33 PST 1970, Sat Jan 10 23:24:33 PST 1970], actual = [Sat Jan 10 16:00:00 PST 1970,Thu Jan 01 16:00:00 PST 1970,Wed Dec 31 16:00:00 PST 1969] . For element 13, expected = [Wed Dec 31 16:33:27 PST 1969, Thu Jan 01 16:44:27 PST 1970, Sat Jan 10 23:24:33 PST 1970, Sat Jan 10 23:24:33 PST 1970, Sat Jan 10 23:24:33 PST 1970], actual = [Sat Jan 10 16:00:00 PST 1970,Thu Jan 01 16:00:00 PST 1970,Wed Dec 31 16:00:00 PST 1969] . For element 18, expected = [2007908.54548, 0.544, 3002323232.545454, 64564645656.78657, 4564565465.2342], actual = [64564645656.786570,3002323232.545454,4564565465.234200,0.544000,2007908.545480] . For element 19, expected = [2007908.54548, 0.544, 3002323232.545454, 64564645656.78657, 4564565465.2342], actual = [64564645656.786570,3002323232.545454,4564565465.234200,0.544000,2007908.545480] . For element 30, expected = [-1.0E12, 1.0E12, 1.0E12, 9.9999954E11, 9.9999941E11], actual = [1.0E12,-1.0E12,9.9999941E11,9.9999954E11] . For element 31, expected = [-1.0E12, 1.0E12, 1.0E12, 9.9999954E11, 9.9999941E11], actual = [1.0E12,-1.0E12,9.9999941E11,9.9999954E11] . For element 32, expected size = 5, actual size = 4 . at org.apache.jdo.tck.JDO_Test.fail(JDO_Test.java:546) at org.apache.jdo.tck.models.fieldtypes.TestCollectionCollections.checkValues(TestCollectionCollections.java:154) at org.apache.jdo.tck.models.fieldtypes.TestCollectionCollections.runTest(TestCollectionCollections.java:100) at org.apache.jdo.tck.models.fieldtypes.TestCollectionCollections.test(TestCollectionCollections.java:70) 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:204) at org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:115) at org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:93)
The differences are down to
1. SQL DATE type being used in the schema when it should be using TIMESTAMP. If you want to store a java.util.Date you should use SQL TIMESTAMP. The schema needs changing to do this. This is a TCK issue. 2. Duplicates being thrown away. This is a JPOX issue for Collection type only (Collection is mapped internally to Set) - all other container types should be fine here. 3. Ordering not preserved. This is a JPOX issue for Collection type only (Collection is mapped internally to Set) - all other container types should be fine here. Issue 2 and 3 above are now fixed in JPOX CVS - JPOX builds dated 05/10/2005 or later have this. The test now gives
Expected and observed do not match!! For element 12, expected = [Thu Jan 01 01:33:27 GMT 1970, Fri Jan 02 01:44:27 GMT 1970, Sun Jan 11 08:24:33 GMT 1970, Sun Jan 11 08:24:33 GMT 1970, Sun Jan 11 08:24:33 GMT 1970], actual = [Thu Jan 01 01:00:00 GMT 1970,Fri Jan 02 01:00:00 GMT 1970,Sun Jan 11 01:00:00 GMT 1970,Sun Jan 11 01:00:00 GMT 1970,Sun Jan 11 01:00:00 GMT 1970] . For element 13, expected = [Thu Jan 01 01:33:27 GMT 1970, Fri Jan 02 01:44:27 GMT 1970, Sun Jan 11 08:24:33 GMT 1970, Sun Jan 11 08:24:33 GMT 1970, Sun Jan 11 08:24:33 GMT 1970], actual = [Thu Jan 01 01:00:00 GMT 1970,Fri Jan 02 01:00:00 GMT 1970,Sun Jan 11 01:00:00 GMT 1970,Sun Jan 11 01:00:00 GMT 1970,Sun Jan 11 01:00:00 GMT 1970] . For element 18, expected = [2007908.54548, 0.544, 3002323232.545454, 64564645656.78657, 4564565465.2342], actual = [2007908.545480, 0.544000, 3002323232.545454, 64564645656.786570,4564565465.234200] . For element 19, expected = [2007908.54548, 0.544, 3002323232.545454, 64564645656.78657, 4564565465.2342], actual = [2007908.545480, 0.544000, 3002323232.545454, 64564645656.786570, 4564565465.234200] . which seems to come down to issue 1 above in the schema, and to the comparison of floating point fields (which are never likely to be exact after writing to and retrieving from an RDBMS - should do a comparison with an amount +/- IMHO). Thanks for your analysis, Andy. I fixed the schema so that the dates are mapped to a TIMESTAMP column. The issue with the date fields is resolved and several other test that failed now pass.
Michelle Caisse made changes - 05/Oct/05 05:34 AM
Michelle Caisse made changes - 05/Oct/05 05:35 AM
Michelle Caisse made changes - 05/Oct/05 06:00 AM
The BigDecimal fields (18 and 19) fail to match because when they are read from Derby the values are padded with zeroes to 6 decimal places, the specified scale. We had this problem with TestFieldsOfBigDecimal and changed the test to use compareTo() rather than equals(). In this test, we use the equals() method of Vector, which presumably delegates to the equals method of the objects in the Vector. In attempting to add some code to further test the Collection of BigDecimal fields, I encounter the following problem:
I want to loop through the elements of the Collection of BigDecimal and test them individually. The Collection is instantiated as a Vector. I can get the elements of the expected value using the Vector elementAt() method. However, when I attempt to cast the value read from the datastore to a Vector to find its elements, I get a runtime ClassCastException. When I print out val.getClass().getName(), I get java.util.Vector for the expected value class, but org.jpox.sco.Collection for the actual value read from the datastore. The reason you get a "org.jpox.sco.Collection" when inspecting the type of the collection field *whilst within the transaction* is that a JDO implementation has to be able to detect changes to the Collection field (addition of elements, removal of elements, etc). If you'd done it outside the transaction then it would have been java.util.Vector. The TCK cannot justifiably test for the type of the collection field (since it may be a JDO impl wrapper type) but it can justifiably test for whether it is "instanceof" the expected type. The error in that particular part is that JPOX is assigning a wrapper type of the declared type and not of the instantiated type, and consequently the cast fails.
Andy Jefferson made changes - 05/Oct/05 04:59 PM
JPOX CVS now has the necessary changes so that the wrapper type used is based on the instantiated type rather than the declared type. As a result, any JPOX builds dated 06/10/2005 onwards will allow you to cast the type of the collection field to be a Vector and then you ought to be able to use List methods. This last part is not tested, but should at least allow further progress on the BigDecimal issue.
Andy Jefferson made changes - 06/Oct/05 02:25 AM
I've added a block of code testing for non-trivial differences in the BigDecimal fields. However, I still get a ClassCastException with this test .
Michelle Caisse made changes - 11/Oct/05 05:49 AM
Thanks Michelle.
Well I'll explain what the problem is, and some options. The test creates an object with many collections and instantiates them as Vectors (as you know). It tries to persist it, and JPOX converts all Collection fields to the equivalent wrapper type for the _instantiated_ type of the field. This is fine. The test then goes back to the datastore and retrieves the persisted object. JPOX has to look at what is in the datastore for each Collection field and create a suitable Collection. At this point it has no idea that the user wants a Vector creating since the instantiated type is not stored in the datastore anywhere. Consequently it knows it has to create a Collection type, and that the user has provided an <order>, so it create an ArrayList (since that is the JPOX-defined default for Lists). How is JPOX to know that it should instantiate the fields as Vector when it is simply retrieving an object from the datastore and the declared type of the field is Collection ? JPOX calls the default constructor of CollectionCollections and then has to instantiate each field somehow. So it takes a guess. If anyone thinks it should do better, then please please define how. What I would do to the test is change your "Vector.elementAt(i)" calls to be "List.get(i)" (since List.get(i) is more generic and does the same thing as Vector.elementAt(i)), and cast the Collection field to a List instead of a Vector. This will work because JPOX (CVS) has given it a List wrapper. Hope that makes sense.
Andy Jefferson made changes - 22/Oct/05 07:01 PM
Implemented change suggested by Andy. Also now do comparison with the expected value as object whose equals method is being invoked. Now the test gives a ClassCastException on List.actualL only in the case where the field is serialized. Debug statements show that the field is not an instance of Vector.
Michelle Caisse made changes - 27/Oct/05 07:30 PM
JPOX CVS also now creates wrappers for serialised fields based on the declared type.
This results in the test passing.
Andy Jefferson made changes - 28/Oct/05 01:08 AM
Michelle Caisse made changes - 01/Nov/05 06:39 AM
Reopened to set the Fix Version/s field to JDO 2 beta.
Michael Bouschen made changes - 23/Apr/06 03:08 AM
Michael Bouschen made changes - 23/Apr/06 03:10 AM
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Closed
Major
Incorrect value for public Collection CollectionOfDate12
JDO2 spec section 18.5 states that the default "jdbc-type" for a java.util.Date will be TIMESTAMP, yet the test uses DATE and doesn't specify it in the "orm" file.