From dev-return-8892-apmail-openjpa-dev-archive=openjpa.apache.org@openjpa.apache.org Tue Aug 05 17:31:08 2008 Return-Path: Delivered-To: apmail-openjpa-dev-archive@www.apache.org Received: (qmail 80437 invoked from network); 5 Aug 2008 17:31:07 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 5 Aug 2008 17:31:07 -0000 Received: (qmail 298 invoked by uid 500); 5 Aug 2008 17:31:04 -0000 Delivered-To: apmail-openjpa-dev-archive@openjpa.apache.org Received: (qmail 197 invoked by uid 500); 5 Aug 2008 17:31:04 -0000 Mailing-List: contact dev-help@openjpa.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@openjpa.apache.org Delivered-To: mailing list dev@openjpa.apache.org Received: (qmail 143 invoked by uid 99); 5 Aug 2008 17:31:04 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 05 Aug 2008 10:31:04 -0700 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.140] (HELO brutus.apache.org) (140.211.11.140) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 05 Aug 2008 17:30:17 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id 57054234C198 for ; Tue, 5 Aug 2008 10:30:44 -0700 (PDT) Message-ID: <347860645.1217957444355.JavaMail.jira@brutus> Date: Tue, 5 Aug 2008 10:30:44 -0700 (PDT) From: "Michael Dick (JIRA)" To: dev@openjpa.apache.org Subject: [jira] Assigned: (OPENJPA-628) Issue Found With Recursive One-To_Many Relations in 1.1.0 In-Reply-To: <1268334356.1213027545026.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/OPENJPA-628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dick reassigned OPENJPA-628: ------------------------------------ Assignee: Michael Dick > Issue Found With Recursive One-To_Many Relations in 1.1.0 > --------------------------------------------------------- > > Key: OPENJPA-628 > URL: https://issues.apache.org/jira/browse/OPENJPA-628 > Project: OpenJPA > Issue Type: Bug > Components: kernel > Affects Versions: 1.1.0 > Environment: Does not appear to be affect by environment (OS or DB Platform) > Reporter: Robert Krier > Assignee: Michael Dick > Priority: Critical > Fix For: 1.2.0 > > Attachments: One2Many_issue_1.1.0.zip > > > There seems to be an issue with recursive one-to-many relations that did not exist prior to 1.1.0. I have tested my scenario on both 1.0.1 and 1.0.2 and the behavior works as expected, but the exact same scenario does not work under 1.1.0. It seems that level two joins do not persist on an update of an object graph. > To illustrate my problem I've included the source and a application to run the test. The entity classes are as follows: > 1) A given "Tree" object holds one-to-many "Node" objects. "Tree" is neither derived by nor derived from any other classes. > 2) A given "Node" object holds one-to-many child "Node" objects. "Node" is neither derived by nor derived from any classes. > Scenario 1: > 1) Create a "Tree" object. > 2) Add one or more "Node" objects to "Tree" > 3) Add one or more child "Node" objects to one or more of the "node" objects associated with "tree". > 4) Persist and commit "tree". > 5) Close the entity manager. > Result: The tree, nodes and child nodes are persisted to the database as expected. Referential integrity is correct. > Scenario 2: > 1) Create a "Tree" object. > 2) Add one or more "Node" objects to "Tree" > 3) Persist and commit the tree. > 4) Close the entity manager. > Result: The tree and nodes are persisted to the database as expected. > 5) Read the "tree" from a new entity manager > 6) Add child nodes to one or more of the "nodes" objects associated with "tree" > 7) Commit the "tree" > 8) Close the entity manager. > Result: Under 1.0.1 and 1.0.2, the child nodes are persisted to the database as expected. Referential integrity is correct. Under 1.1.0, the child nodes are not persisted to the database. No errors or exceptions are thrown. This appears to be broken with the 1.1.0 release. > I have included my test application for you to review. The test was run against a SQL Server database, however you should be able to easily modify the persistence.xml file to run against any database platform you wish. The table structure is as follows: > Counters: > PrimKey: NUMERIC(18,0) (18,0) PrimaryKey, NOT NULL > Counter: NUMERIC(18,0) (18, 0) NOT NULL > > Trees: > OID: NUMERIC(18,0) PrimaryKey, NOT NULL > ParentOID: NUMERIC(18,0) NULL > Sequence: NUMERIC(18,0) NULL > Name: VARCHAR(50) NOT NULL > Version: NUMERIC(18,0) NOT NULL > Nodes: > OID: NUMERIC(18,0) PrimaryKey, NOT NULL > Name: VARCHAR(50) NOT NULL > Version: NUMERIC(18,0) NOT NULL > Please let me know if you have any questions. Thanks for your attention into this matter. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.