(reposting here from forum)
Consider:
a table with an assigned PK (i.e. not auto-increment), let's call this "A"
Another table ("B") linked to the table listed above but with it's PK set to auto-increment.
Now if you try to save B with cascading switched on, it will break. From the little debugging I've done it looks like:
a) hibernate detects that A needs to be saved first, but puts it into some sort of queue.
b) when it hits B, it short-circuits this save queue and tries to save B immediately so as to obtain a PK reference for B. This fails since A hasn't been yet been saved so it's link is still null.
Schema used is listed below (MySQL):
CREATE DATABASE `jira` /*!40100 DEFAULT CHARACTER SET latin1 */;
DROP TABLE IF EXISTS `jira`.`parent`;
CREATE TABLE `jira`.`parent` (
`parent_id` int(10) unsigned NOT NULL,
PRIMARY KEY (`parent_id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
DROP TABLE IF EXISTS `jira`.`child`;
CREATE TABLE `jira`.`child` (
`child_id` int(10) unsigned NOT NULL auto_increment,
`parent_id` int(10) unsigned NOT NULL,
PRIMARY KEY (`child_id`),
KEY `FK_child_1` (`parent_id`),
CONSTRAINT `FK_child_1` FOREIGN KEY (`parent_id`) REFERENCES `parent` (`parent_id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
tested on MySql, and hibernate versions (with annotations) v3.2.4 to 3.3.0CR1
I've checked in the fix for to Branch_3_3 and trunk.
Wallace, you'll still need to use Session.merge() for your issue in those branches.
I've added a FailureExpected test that reproduces this issue in Branch_3_5 and trunk:
org.hibernate.test.cascade.CascadeTestWithAssignedParentIdTest.testSaveChildWithParentFailureExpected()
Fixed in trunk and Branch_3_5.
Wallace, thanks for your test case and the fix. I don't see a need for executing the inserts before and after cascadeBeforeSave(), so I've simply moved that code to where you suggested. This way the inserts can be executed in 1 batch instead of 2.
Bulk closing stale resolved issues