From jdo-dev-return-8869-apmail-db-jdo-dev-archive=www.apache.org@db.apache.org Fri Nov 19 20:26:14 2010 Return-Path: Delivered-To: apmail-db-jdo-dev-archive@www.apache.org Received: (qmail 81182 invoked from network); 19 Nov 2010 20:26:11 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 19 Nov 2010 20:26:11 -0000 Received: (qmail 96023 invoked by uid 500); 19 Nov 2010 20:26:41 -0000 Mailing-List: contact jdo-dev-help@db.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: jdo-dev@db.apache.org Delivered-To: mailing list jdo-dev@db.apache.org Received: (qmail 95985 invoked by uid 99); 19 Nov 2010 20:26:41 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 19 Nov 2010 20:26:41 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.22] (HELO thor.apache.org) (140.211.11.22) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 19 Nov 2010 20:26:38 +0000 Received: from thor (localhost [127.0.0.1]) by thor.apache.org (8.13.8+Sun/8.13.8) with ESMTP id oAJKQHeo024075 for ; Fri, 19 Nov 2010 20:26:17 GMT Message-ID: <25107207.203791290198377065.JavaMail.jira@thor> Date: Fri, 19 Nov 2010 15:26:17 -0500 (EST) From: "Craig L Russell (JIRA)" To: jdo-dev@db.apache.org Subject: [jira] Commented: (JDO-669) TCK : RelationshipManyToManyAllRelationships.testDeleteFromMappedSide - problem with check In-Reply-To: <24286637.201251290193575485.JavaMail.jira@thor> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/JDO-669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12933958#action_12933958 ] Craig L Russell commented on JDO-669: ------------------------------------- It's a test case bug. It's not permitted to access a persistent field after the object has been deleted. The test case should be changed to perform a different check to see if the deleted instance is in the collection. This can be done by saving the id before deleting the instance and later checking to see if any of the instances in the collection have that id. > 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 > > > 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 > Read access to primary key fields is permitted. Any other access to persistent fields is not supported and might throw a JDOUserException. > 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.