Community
Participate
Working Groups
Build Identifier: 2.1.1.v20100817-r8050 Environment: * Fedora 13 * Java 1.6.0_21 32-bit * EclipseLink 2.1.1.v20100817-r8050 * MySQL server 5.0.88 * Connector/J 5.1.12 Data model: ClassA1 - Abstract, InheritanceType.JOINED ClassA2 - Sub-classed from ClassA1, OneToMany mapping (CascadeType.ALL) to ClassB2 (List<ClassB2>) ClassB1 - Abstract, InheritanceType.JOINED ClassB2 - Sub-classed from ClassB1, ManyToOne mapping to ClassA2 In the database, a foreign key constraint exists in the ClassB2 table on the ClassA2 table. Test case: 1. ClassA2 instance is constructed 2. ClassB2 instance added as child to ClassA2 instance 3. Persist ClassA2 Cascade persist of ClassB2 instance fails because the persist order is: 1. ClassA1 2. ClassB1 3. ClassB2 (Error: ClassA2 not persisted yet - foreign key constraint violation) The correct persist order should be: 1. ClassA1 2. ClassA2 3. ClassB1 4. ClassB2 This bug exists in 2.1.0 and 2.1.1. The bug does not exist in any previous version. Reproducible: Always Steps to Reproduce: 1. Unpack the attached EclipseLinkBugTest3.zip test case 2. Create the tables in a local MySQL 5.x database using the following script: EclipseLinkBugTest3/src/main/resources/create-schema.sql 3. Edit EclipseLinkBugTest3/src/main/resources/META-INF/persistence.xml and change the following properties to connect to a local MySQL 5.x database: * javax.persistence.jdbc.url * javax.persistence.jdbc.user * javax.persistence.jdbc.password 4. cd EclipseLinkBugTest3 5. Compile and run with Maven 2.2 (and change java path accordinly). Example: mvn -Dexec.classpathScope=runtime -Dexec.args="-classpath %classpath ca.avant.test.App" -Dexec.executable=/usr/local/java/1.6.0_21/bin/java process-classes org.codehaus.mojo:exec-maven-plugin:1.1.1:exec
Created attachment 179766 [details] Test case (Maven project) A complete test case as a Maven project.
Created attachment 179767 [details] Output log for EclipseLink 2.1.1 with error A log file showing the error with EclipseLink 2.1.1.
Created attachment 179768 [details] Output log using EclipseLink 2.0.2 (successful) The output log on the same test case using EclipseLink 2.0.2. The test case works OK.
Targetting for 2.1.3 - the next open patch. Assuming this is actually a regression, this should be fixed for the next patch.
This appears to be an issue with the constraints in the DDL you have provided. When I run with EclipseLink-created DDL (that also includes constraints), everything works fine. The EclipseLink DDL creates the constraint between B2 and A1 instead. That is how your DDL should be constructed. There are ways to manually alter the commit order if you want, but you should be very careful about using them to ensure the new order works for all use cases in your application.
(In reply to comment #5) > This appears to be an issue with the constraints in the DDL you have provided. > When I run with EclipseLink-created DDL (that also includes constraints), > everything works fine. The EclipseLink DDL creates the constraint between B2 > and A1 instead. That is how your DDL should be constructed. > > There are ways to manually alter the commit order if you want, but you should > be very careful about using them to ensure the new order works for all use > cases in your application. I agree that your suggestion makes sense in the context of the test case, but the more complete data model our software uses is more like this: A1 B1 / \ / \ / A2.2 <----FK---- B2.2 \ / \ A2.1 <------------FK----------- B2.1 A2.1 and A2.2 both sub-class A1 B2.1 and B2.2 both sub-class B1 A2.1 can only have a collection of B2.1 entities A2.2 can only have a collection of B2.2 entities If both B2.1 and B2.2 had foreign key references to A1, then the DB constraints can theoretically allow a one-to-many relationship from A2.2 to B2.1, or A2.1 to B2.2. This is actually disallowed in the way we defined the JPA entity relationships, but we attempted to have the DB constraints reflect the entity model exactly. I would expect EclipseLink to persist A1, A2.1 (or A2.2), B1, and then B2.1 (or B2.2). It works with EclipseLink 1.1.x and 2.0.x, so why does it no longer work with EclipseLink 2.1.x?
This issue has nothing to do with Commit Order. Our Commit order is correct in all versions. We seem to be missing an Insert into the A2 table. I wonder if this is related to some feature interaction with MySQL native sequencing. I'll take another look.
This change in behavior is caused by the fix for bug 310015 and bug 310505. The issue here is that the DB has constraints the EclipseLink does not know about. EclipseLink cannot properly calculate which statements it can defer without knowing that information. Your should be able to address this issue in a DescriptorCustomizer. In the DescriptorCustomizer, you can do one of the following 1. change the mapping so that the foreign reference points to the subclass table - In JPA we default the mapping to point to the primary table. 2. call descriptor.setHasMultipleTableConstraintDependecy(true) on the child descriptor
The Eclipselink project has moved to Github: https://github.com/eclipse-ee4j/eclipselink
