db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andy Jefferson <a...@datanucleus.org>
Subject TCK "Relationship1ToManyAllRelationships.testDeleteFromMappedSide"
Date Mon, 06 Apr 2009 08:45:51 GMT
During the course of improving DataNucleus handling of managed relations I 
have come across a problem with the above TCK test. We have a 1-N relation 
and delete an element via deletePersistent. This is then to remove the 
element from the collection. After the deletePersistent() and flush() it 
tries to check collection.contains() with the deleted element. Internally we 
use a HashSet for that collection and so there is use of hashcodes. This 
(after my changes to DataNucleus) results in

    [java]      at 
    [java]      at 
    [java]      at 
    [java]      at 
    [java]      at 
    [java]      at java.util.HashMap.getEntry(HashMap.java:344)
    [java]      at java.util.HashMap.containsKey(HashMap.java:335)
    [java]      at java.util.HashSet.contains(HashSet.java:184)
    [java]      at org.datanucleus.sco.backed.Set.contains(Set.java:469)
    [java]      at 
    [java]      at 

so it tries to find the position of this (deleted) object in the HashSet and 
tries to work out the hashcode of the deleted object ... hence provoking an 
attempt to load the person id (since Person defines hashCode() as that). But 
the element is deleted hence the exception.

If I manually inspect the Collection of elements using an iterator and do a 
comparison via JDOHelper.getObjectId() with the deleted object this should 
pass since the deleted object isn't present.

Could we get the TCK test changed to make use of iterator() and comparison 
with ids etc to avoid this hashcode complication ?

Why did it work prior to my DN changes ? likely because the collection wasn't 
loaded and so the contains went straight to the datastore hence not provoking 
the load of fields of a deleted object.

Andy  (DataNucleus - http://www.datanucleus.org)

View raw message