db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoff hendrey <geoff_hend...@yahoo.com>
Subject my old TCK notes
Date Thu, 19 May 2005 04:18:06 GMT
These are notes I gathered from the last version of
the TCK I ran (not what I just got from Apache, but
maybe some of the problems remain, we'll see). These
are notes on the test source code itself. I'm not
looking for any feedback on this, jut thought I would
toss it out there.


Package: com.sun.jdotck.api.PersistenceManager
==============================================
 [test class = GetObjectIdClass]
    contains hardcoded reference to RI's OID class.
    c1.getName().equals("com.sun.jdori.fostore.OID")
    This causes non-RI to wrongly fail.

 [test class =
ConcurrentPersistenceManagerSameClasses]
    Does not properly cleanup PCPoint and PCRect
objects. COnsequently, if the 
    test is run more than once, it fails the second
time. The reason for 
    failure is because the "findPoint" method issues a
jdo query, and uses
    the first object returned by the query's iterator.
However, there may
    be multiple objects in the iterator. The test then
goes on to compare the
    JAVA identity of said first object with the JAVA
identity of the object
    made persistent earlier in the transaction. This
leads to a failure with
    a message:
    "Found PCPoint: 110, 120
    Expected: 110, 120"

    This test would be fixed by deleting all objects
matching the query BEFORE
    doing the first insert, or by changing the test
comparison from JAVA 
    identity to 110==p11a.getX() && 120==p11a.getY()

    [test = OneInstanceOfObjectPerPersistenceManager]
    this test cannot be run twice in a row without
clearing the database. Query
    findPoint (int x, int y) will simply find a point
from a previous run. Since
    we're using datastore identity, the object
retrieved from the query will be
    different since it has a different database pk.
this results in Failed. 
    "Assertion A5.4-2 failed; query results differ"

    [test = RefreshSideEffects]
    While not stricktly a bug, this test cannot be run
twice in a row from the 
    same JVM. This is because PersistenceCapable "n1"
is declared as static.
    The second time the test is run,
"makePersistent(n1)" is called on a different
    persistence manager, while n1 remains in the cache
of the first pm. This
    is illegal. This problem also manifests itself in
all tests begining with
    "Refresh".

Package: com.sun.jdotck.api.InstanceCallbacks
=============================================
    [test class = CallingJdoPreClear]
    in InstanceCallbackClass.jdoPreClear the following
line causes a 
    NullPointerException because children is null:
    <code>
    ...
    numberOfChildren[intValue] = children.size();
    ...
    </code>
    children is not in the default-fetch-group and
never gets loaded within the 
    transaction for the PC "primaryObj". The 
    "touchFields" method never touches
primaryObj.children, thus it remains 
    null, having been set null in the transition to
HOLLOW caused by the prior
    commit. Because jdoPreClear is not modified by the
enhancer, children does 
    not get loaded when jdoPreClear is called and the
NullPointerException is 
    thrown. This could be fixed by modifying the
"instanceCallbacks.jdo" meta-
    data to add default-fetch-group="true" for the
field 'children'.

package: com.sun.jdotck.models.company
=======================================
    [test class = Company]
    in constructor, parameter 'addr' is not assigned
to instance variable 
    'address'
    <code>
        address = address
    </code>
    should be changed to "this.address = addr;"

package: com.sun.jdotck.models.fieldtypes
=======================================
    [test class = TestFieldsOfObject]
    The default value for Object0 is null. When the
test forces garbage
    collection via System.gc(), the PC is garbage
collected. When the PC is
    materialized from the datastore on getObjectById,
a new instance of the PC 
    is constructed. Because Object0 is not persistent,
val assumes null default
    value. This causes a null pointer exception when
!val.equals(startValue) 
    is evaluated. The solution is to properly set the
value of isPersistent[0]
    to false. This test incorrectly has set
isPersistent[0] to true. If the 
    value of isPersistent[0] is set to false, the
offending block of code is
    correctly skiped and the null pointer avoided.
    
    The same error will be caused for several
non-persistent fields.
    All of the following indexes of isPersistent
should be false, not true:
    0,16,36,52,72,88,108,124

    [test class = TestFieldsOfSimpleInterface]
    The problem is identical to that of
TestFieldsOfObject.
    All of the following indexes of isPersistent
should be false, not true:
    0,16,36,52,72,88,108,124

    [test class = TestCollectionCollections]
    Should not use Vector, since application is not
required to support
     Collection or Set unless they reference a
HashSet. Causes a 
     ClassCastException to be thrown.

package: com.sun.jdotck.models.inheritance
=======================================
    [test class = NonpersistentSuperclass]
    Any time a superclass field is referenced, I had
to modify the source to 
    cast the object to the concrete class containing
the field. For example,
    c.floatE must be changed to
((TopNonPersistE)c).floatE, because the field
    floatE is contained in uphierarchy class
TopNonPersistE. If I do not do this
    a NoSuchMethodException is thrown from within the
enhanced class. I believe
    this to be a bug in the reference enhancer. From
now on I'll call this 
    SUPERCLASS_ENHANCED_FIELD_BUG

    Also, this test depends on restoreValues=true, but
does not setup 
    restoreValues to be true. I had to set
restoreValues=true in iut.properties.

    [test class = FieldWithSameNameInSuperclass]
    SUPERCLASS_ENHANCED_FIELD_BUG and
    Enancer does not appear to be enhancing
FieldSameName4.n3 or 
    FieldSameName3.n1. In the case of
FieldSameName3.n1 this is correct because
    FieldSameName2 declares
persistence-modifier="none" in metadata, so n1 should
    not be persistent in FieldSameName3. But it does
look like FieldSameName4.n3
    should be enhanced.

    Mutators get/setIntH in FieldsSameName4 access
FieldsSameName4.n3, which
    explains the messages printed by the test below.
However, the parts of
    the test that say "intF should be ..." represent
an erroneus check against
    non-enhanced field FieldsSameName3.n1. Since the
fiels is not enhanced, it
    would not get restored.

    "
    Object reverted to transient after rollback. 
Persistent attribute shortF is 25, it should be 394
    Object reverted to transient after rollback. 
Persistent attribute intH is 26, it should be -347600
    Read object back after rollback.  Persistent
attribute shortF is 6, it should be 258
    Read object back after rollback.  Persistent
attribute intH is 7, it should be -25
    Read object back after rollback.  Persistent
attribute shortF is 15, it should be 8
    Read object back after rollback.  Persistent
attribute intH is 16, it should be -603
    "
    
    [test class =
NonPersistentFieldsAreNonPersistentInSubclass]
    SUPERCLASS_ENHANCED_FIELD_BUG
    
    [test class =
TransactionalFieldsAreTransactionalInSubclasses]
    SUPERCLASS_ENHANCED_FIELD_BUG
    here is an example of the error produced by
SUPERCLASS_ENHANCED_FIELD_BUG
    "Failed. Class linking error while trying to load
test class
`com.sun.jdotck.models.inheritance.TransactionalFieldsAreTransactionalInSubclasses':
java.lang.NoSuchMethodError:
com.sun.jdotck.models.inheritance.AllPersist4.jdoSetthirdObj(Lcom/sun/jdotck/models/inheritance/AllPersist4;Lcom/sun/jdotck/models/inheritance/AllPersist4;)V"

    [test class =
PersistentFieldsArePersistentInSubClasses]
    SUPERCLASS_ENHANCED_FIELD_BUG
    For datastore identity, the AllPersist equals
method is broken. 
    Equals will fail with a ClassCastException if obj
is an
    AllPersist. Basically this method cannot return
true unless *application*
    identity is used! Since I am testing with
Datastore identity, both the equals
    and hashcode methods should not be changes from
their defaults in Object.
    Therefore I commented them out. 

package: com.sun.jdotck.query.operators
=======================================
NOTE: None of these tests in this package passes
completely due to bogus 
      comparisons of floats to ints, etc. The spec
warns against doing such 
      comparisons, so I take these "failures" with a
grain of salt.

    [test =
com.sun.jdotck.query.operators.BinaryAddition]
    This tests is broken. the first thing it does in
execute an invalid filter,
    which naturally throws an exception (which the
test is not coded to catch).
    To get the test beyond the initial exception, I
commented out the bunk query.
    This test also erroneously compares the characters
'o' and 'E' to the integer
    1+8. It also erroneusly compares 1+8 to a very
large random integer value.
    The error messages print nothing to indicate why
the test failed. I inserted
    a print to show the error:
    Executing test BinaryAddition() ...
    Size = 1
    Object is PrimitiveTypes(9)
    Size = 1
    Object is PrimitiveTypes(9)
    Size = 1
    Object is PrimitiveTypes(9)
    Size = 1
    Object is PrimitiveTypes(9)
    error, Size = 0but expected size() = 0 for filter:
charNotNull == 1 + 8
    Size = 1
    Object is PrimitiveTypes(9)
    Size = 1
    Object is PrimitiveTypes(9)
    Size = 1
    Object is PrimitiveTypes(9)
    Size = 1
    Object is PrimitiveTypes(9)
    Size = 1
    Object is PrimitiveTypes(9)
    Size = 1
    Object is PrimitiveTypes(9)
    error, Size = 0but expected size() = 0 for filter:
charNull == 1 + 8
    Size = 1
    Object is PrimitiveTypes(9)
    Size = 1
    Object is PrimitiveTypes(9)
    Size = 1
    Object is PrimitiveTypes(9)
    error, Size = 0but expected size() = 0 for filter:
bigInteger == 1 + 8


    [test =
com.sun.jdotck.query.operators.GreaterThanOrEqual]
    MySql comparisons of BigInt broken when BigInt
represented as String.
    Example: SELECT  "-999999999999999999" =
-999999999999999999
    returns 0. Should return 1 since MySQL supposed to
convert string to number
    when one argument of arithmetic is number and
other is String.

    This causes:
    JDOQL GreaterThanOrEqual test returns wrong number
of instances with filter "fld_BigInteger >= value",
parameter "java.math.BigInteger value"
    Expected 10 Got 9

    ordering of String comparisons is not specified by
the spec. 
    MySQL: SELECT  "JDO" >= "abcde" will return 1.
Therefore the 
    following should not be errors:

    JDOQL GreaterThanOrEqual test returns incorrect
value with filter "value >= fld_String", parameter
"String value"
    Retrieved value: abcde, with parameter value: JDO

    JDOQL GreaterThanOrEqual test returns incorrect
value with filter "value >= fld_String", parameter
"String value"
    Retrieved value: abcdef, with parameter value: JDO

    JDOQL GreaterThanOrEqual test returns incorrect
value with filter "value >= fld_String", parameter
"String value"
    Retrieved value: Java, with parameter value: JDO

    JDOQL GreaterThanOrEqual test returns incorrect
value with filter "value >= fld_String", parameter
"String value"
    Retrieved value: hello world, with parameter
value: JDO

    JDOQL GreaterThanOrEqual test returns incorrect
value with filter "value >= fld_String", parameter
"String value"
    Retrieved value: Java, with parameter value: JDO

    JDOQL GreaterThanOrEqual test returns wrong number
of instances with filter "value >= fld_String",
parameter "String value"
    Expected 2 Got 7

    JDOQL GreaterThanOrEqual test returns wrong number
of instances with filter "fld_String >= value",
parameter "String value"
    Expected 9 Got 4

    JDOQL GreaterThanOrEqual test returns wrong number
of instances with filter "value.fld_String >=
fld_String", parameter
"com.sun.jdotck.models.fieldtypes.AllTypes value"
    Expected 8 Got 2

    JDOQL GreaterThanOrEqual test returns incorrect
value with filter "fld_String >= "Java""
    Retrieved value: JDO has a very nice persistence
API, with parameter value: Java

    JDOQL GreaterThanOrEqual test returns incorrect
value with filter "fld_String >= "Java""
    Retrieved value: JDO, with parameter value: Java

    JDOQL GreaterThanOrEqual test returns incorrect
value with filter "fld_String >= "Java""
    Retrieved value: JDO is a breeze to use, with
parameter value: Java

    JDOQL GreaterThanOrEqual test returns wrong number
of instances with filter "fld_BigInteger >= value",
parameter "java.math.BigInteger value"
    Expected 10 Got 9

    [test = com.sun.jdotck.query.operators.Equality]
    The following fail:
    <code>
    run_intQuery(int_filterL, floatParameter, new
Float(Integer.MAX_VALUE), Integer.MAX_VALUE, 1);
    run_intQuery(int_filterR, floatParameter, new
Float(Integer.MIN_VALUE), Integer.MIN_VALUE, 1);
    </code>
    This is because rounding of Integer.MaxValue and
Integer.MIN_VALUE. This is
    expected. Don't try to compare floats to ints.
Same goes for BigInteger, int,
    Long, etc. This test has many bogus comparisons.

    [test =
com.sun.jdotck.query.operators.GreaterThan]
    Bogus comparisons of floats to ints, String to
String, etc., fail due to
    rounding.
    [test = com.sun.jdotck.query.operators.LessThan]
    Bogus comparisons of floats to ints, String to
String, etc., fail due to
    rounding or DB ordering or string comparisons.
    [test = com.sun.jdotck.query.operators.NotEquals]
    Bogus comparisons of floats to ints, String to
String, etc., fail due to
    rounding or DB ordering or string comparisons.
    [test =
com.sun.jdotck.query.operators.LessThanOrEqual]
    Bogus comparisons of floats to ints, String to
String, etc., fail due to
    rounding or DB ordering or string comparisons.

package: com.sun.jdotck.query
=============================
    [test =
ExecutingMultipleQueriesSimultaneouslyIsThreadSafe]
    If this test executed a single query in each pm,
simultaneously this test would pass.
    But, the same query is executed multiple times
inside a single transaction.
    This causes deadlock, see explaination below. This
deadlock is unavoidable
    even if the queries are ordered in the same
direction.

    [test =
MultipleActiveQueryInstanceInSamePersistenceManagerExecutedSimultaneously]
    This test does not, in fact, use the "same
persistence manager" for all the
    queries as is implied by the name. In fact, it
uses a different pm for each
    query, and naturally the queries deadlock as a
result of this. The deadlock 
    occurs because from different PM's, the same
sequence of the same query is 
    executed. PM A locks the rows in the RS. PM B's
query waits for PM A to 
    release the rows. PM A then queries the same rows
again, and deadlocks 
    because B has the next lock. There was a method
commented out
    //pm = getThePM(pmf); This would have done what
the test purports to do. 
    It would have kept a static instance of the PM
that all the simultaneous
    instances would use.
    However, the test would then fail because all the
simultaneous
    instances do a pm.currentTransaction.begin(). And
you can't call begin multiple
    times on the same transaction. So generally, this
test is very screwed up and
    difficult to even think of a way to make it work.




		
__________________________________ 
Yahoo! Mail Mobile 
Take Yahoo! Mail with you! Check email on your mobile phone. 
http://mobile.yahoo.com/learn/mail 

Mime
View raw message