[
https://issues.apache.org/jira/browse/JDO-669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12934794#action_12934794
]
Andy Jefferson commented on JDO-669:
------------------------------------
Patch : better but still not complete.
containsProject, containsEmployee still call xxx.getField() and one of those
objects in the collection could be the deleted one.
an example stack trace (using DN SVN)
[java] 2)
testDeleteFromMappedbySide(org.apache.jdo.tck.mapping.RelationshipManyToManyAllRelationships)javax.jdo.JDOUserException:
Cannot read fields from a deleted object
[java] FailedObject:1882[OID]org.apache.jdo.tck.pc.company.FullTimeEmployee
[java] at
org.datanucleus.jdo.state.PersistentDeleted.transitionReadField(PersistentDeleted.java:116)
[java] at
org.datanucleus.state.AbstractStateManager.transitionReadField(AbstractStateManager.java:551)
[java] at
org.datanucleus.jdo.state.JDOStateManagerImpl.isLoaded(JDOStateManagerImpl.java:2078)
[java] at
org.apache.jdo.tck.pc.company.Person.jdoGetpersonid(Person.java)
[java] at
org.apache.jdo.tck.pc.company.Person.getPersonid(Person.java:104)
[java] at
org.apache.jdo.tck.mapping.AbstractRelationshipTest.containsEmployee(AbstractRelationshipTest.java:80)
[java] at
org.apache.jdo.tck.mapping.RelationshipManyToManyAllRelationships.testDeleteFromMappedbySide(RelationshipManyToManyAllRelationships.java:480)
[java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[java] at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[java] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[java] at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:272)
I think you need collections of the object ids only (before any objects are
deleted), and use these in the comparison
> TCK : RelationshipManyToManyAllRelationships.testDeleteFromMappedSide -
> problem with check
> ------------------------------------------------------------------------------------------
>
> Key: JDO-669
> URL: https://issues.apache.org/jira/browse/JDO-669
> Project: JDO
> Issue Type: Bug
> Components: tck
> Affects Versions: JDO 3
> Reporter: Andy Jefferson
> Assignee: Craig L Russell
> Fix For: JDO 3 maintenance release 1
>
> Attachments: jdo-669.patch
>
>
> Whilst this test passes with current DataNucleus (2.2 M3), I was in the
> process of extending its support for managed relationships, and now get this
> test to fail which provokes this question :-
> pm.deletePersistent(proj1);
> pm.flush();
> deferredAssertTrue(!emp1.getProjects().contains(proj1),
> ASSERTION_FAILED + testMethod, "Postcondition is false; other side of
> relationship not set on flush");
> After the call to deletePersistent() and flush() the object "proj1" is in
> P_DELETED state. So when the call goes in to
> emp1.getProjects().contains(proj) this will interrogate the hashCode() method
> of Project. This is defined as
> public int hashCode() {
> return (int)projid;
> }
> But when using datastore identity "projid" is not a primary-key field, and
> so, as per section 5.5.6 of the spec
> <spec>Read access to primary key fields is permitted. Any other access to
> persistent fields is not supported and might throw a JDOUserException.</spec>
> So what does the implementation do ?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
