Details
-
Type:
Bug
-
Status:
Closed
-
Priority:
Minor
-
Resolution: Invalid
-
Affects Version/s: 2.0.7
-
Fix Version/s: None
-
Component/s: ORM
-
Labels:None
-
Environment:MySQL
Description
I'm getting a database error when deleting and inserting records in a single unit of work. Consider this example:
I have a user and user_info tables. user_info stores additional data about a user as a list of key-values.
user: id, name, email, password
user_info: id, user_id, info_key, info_value
I created a unique index on user_info table: CREATE UNIQUE INDEX `user_info_key` ON `user_info` (`user_id` , `key` ) ;
Each table is represented as an Entity class.
Now, I run this code:
1. $user->removeAllInfo(); // remove old entries
2. $user->addInfo('first_name', 'John'); // add new entries
3. $this->em->flush(); // save
This causes MySQL error: "Integrity constraint violation: 1062 Duplicate entry". Doctrine ORM first persists new entities and then deletes old entities. I think the relevant code is at Doctrine/ORM/UnitOfWork :277-313. Everything works fine if I add flush() before line 2. Also, everything works fine if I change the index to non-unique.
Activity
| Field | Original Value | New Value |
|---|---|---|
| Workflow | jira [ 12993 ] | jira-feedback [ 13964 ] |
| Workflow | jira-feedback [ 13964 ] | jira-feedback2 [ 15828 ] |
| Workflow | jira-feedback2 [ 15828 ] | jira-feedback3 [ 18084 ] |
| Status | Open [ 1 ] | Closed [ 6 ] |
| Assignee | Benjamin Eberlei [ beberlei ] | Marco Pivetta [ ocramius ] |
| Resolution | Invalid [ 6 ] |
- Request to http://www.doctrine-project.org/fisheye/ failed: Error in remote call to 'FishEye 0 (http://www.doctrine-project.org/fisheye/)' (http://www.doctrine-project.org/fisheye) [AbstractRestCommand{path='/rest-service-fe/search-v1/crossRepositoryQuery', params={query=DDC-1359, expand=changesets[-21:-1].revisions[0:29],reviews}, methodType=GET}] : Received status code 503 (Service Temporarily Unavailable)
I just got back to the UnitOfWork and (in latest master) it executes deletes as last operation (maybe to avoid cascades), and this is also documented.
In my opinion, you should do the operation of computing the changeset on your `info` collection manually...