|Foreign Key Constraint Issue Involving One-To-Many and Many-To-One Relationship in EcliplseLink2.1. [message #656552]
||Sat, 26 February 2011 17:47
| No real name
Registered: February 2011
I'm encountering a 1452 error on MySQL 5.5.9 while running some JPA tutorial code that I pulled off the EclipseLink website ( http://wiki.eclipse.org/EclipseLink/Examples/JPA/EmployeeXML), and I'm hoping someone has some insight.
I'm using the latest stable build for EclipseLink as of today from the main website: eclipselink-jpa-modelgen_2.1.2.v20101206-r8635.jar and javax.persistence_2.0.1.v201006031150.jar.
When I populate the database via CreateDatabase.java, I get the following error:
com.mysql.jdbc.exceptions.jdbc4.MySQLIntegrityConstraintViol ationException: Cannot add or update a child row: a foreign key constraint fails (jpatutorial.proj_emp, CONSTRAINT FK_PROJ_EMP_PROJ_ID FOREIGN KEY (PROJ_ID) REFERENCES PROJECT (PROJ_ID)) Error Code: 1452
The relevant models here are an Employee table and a Phone table. There is many-to-one relationship between Phones and Employees. Part of the orm.xml is below:
<table name="PHONE" />
<join-column name="EMP_PH_ID" />
<!-- secondary-table name="SALARY" /-->
<column name="EMP_ID" />
<one-to-many name="phoneNumbers" mapped-by="owner">
The code successfully creates the tables, creates address records for the employees, creates all the employee records, but then fails on inserting a phone record even though it has a valid FK reference to a employee record. I simplified the code so that it executes, persists and commits everything up to the point of the failure, but whether I execute the insert through JPA or manually by running a SQL script, I end up with the same 1452 error.
Interestingly, I found that if I dropped all the related Employee entities, and recreate them off create table definitions reversed engineered by MySQL workbench, I am able to successfully insert records into all the tables through JPA and manually via scripts. So, this suggests Eclipselink is creating the tables in some way that is producing a problem, and MySQL Workbench isn't capturing these problematic definitions in the reverse engineering. At this point, I'm out of ideas.
Powered by FUDForum
. Page generated in 0.10700 seconds