[
https://issues.apache.org/jira/browse/JDO-669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12934906#action_12934906
]
Craig L Russell commented on JDO-669:
-------------------------------------
So instead of a failure you would get an error in the failing case.
It's not obvious to me that it's worth reworking this to change an error to a
failure...
> 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.
