db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andy Jefferson (JIRA)" <j...@apache.org>
Subject [jira] Resolved: (JDO-628) TCK "Relationship1ToManyAllRelationships.testDeleteFromMappedSide" change to use iterator for contains check
Date Fri, 10 Apr 2009 15:33:14 GMT

     [ https://issues.apache.org/jira/browse/JDO-628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Andy Jefferson resolved JDO-628.

    Resolution: Fixed

SVN trunk now has the updated check for containment

> TCK "Relationship1ToManyAllRelationships.testDeleteFromMappedSide" change to use iterator
for contains check
> ------------------------------------------------------------------------------------------------------------
>                 Key: JDO-628
>                 URL: https://issues.apache.org/jira/browse/JDO-628
>             Project: JDO
>          Issue Type: Bug
>          Components: tck2
>    Affects Versions: JDO 2 maintenance release 2
>            Reporter: Andy Jefferson
>            Assignee: Andy Jefferson
>             Fix For: JDO 2 maintenance release 3
> 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.
> The TCK test (and any others that result in an object in P_DELETED state) should be changed
to use iterator() and comparison with the object "id" for contains. This then removes the
problem with use of hashCode()

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message