You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jdo-dev@db.apache.org by Andy Jefferson <an...@datanucleus.org> on 2009/04/06 10:45:51 UTC

TCK "Relationship1ToManyAllRelationships.testDeleteFromMappedSide"

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

FailedObject:4636[OID]org.apache.jdo.tck.pc.company.FullTimeEmployee
    [java]      at 
org.datanucleus.jdo.state.PersistentDeleted.transitionReadField(PersistentDeleted.java:115)
    [java]      at 
org.datanucleus.state.AbstractStateManager.transitionReadField(AbstractStateManager.java:546)
    [java]      at 
org.datanucleus.state.JDOStateManagerImpl.isLoaded(JDOStateManagerImpl.java:1872)
    [java]      at 
org.apache.jdo.tck.pc.company.Person.jdoGetpersonid(Person.java)
    [java]      at 
org.apache.jdo.tck.pc.company.Person.hashCode(Person.java:359)
    [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.util.Collections$UnmodifiableCollection.contains(Collections.java:1000)
    [java]      at 
org.apache.jdo.tck.mapping.Relationship1ToManyAllRelationships.testDeleteFromMappedSide(Relationship1ToManyAllRelationships.java:421)

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.

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

Re: TCK "Relationship1ToManyAllRelationships.testDeleteFromMappedSide"

Posted by Andy Jefferson <an...@datanucleus.org>.
> 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.

Forgot to mention; this only happens with datastore-id since with app-id the 
hashCode() uses the PK fields and they are obviously present hence no load of 
fields is required.



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