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)