-
Notifications
You must be signed in to change notification settings - Fork 2.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DDC-847: EntityManager flush performs insert before remove #5368
Comments
Comment created by romanb: This is not a bug. See DDC-601. |
Issue was closed with resolution "Won't Fix" |
Should it even possible to "solve" a bug with "Won't Fix"? N.B.: DDC-601 is now here: #5109 |
@ureimers that's the wording from the JIRA import that we did last year. |
I see. So it's no bug at all? |
Intended behavior: lemme re-label. |
It's just that this issue seems like a Hydra: You close one and two new pop up. So not fixing it doesn't seem to be the right solution. Or let me rephrase that: There should at least be a workaround like the often mentioned Btw.: Did I just see the labels change while being on the page? Phew... technology today... |
@ureimers if you did find new issues related to this one, please link them and I'll close them too, and create a cross-reference, so that people know what's going on. That's "issue trackers 101" btw... |
And that's rude btw... It was already referenced by MacDada on 26 Mar. And I also updated the broken DDC-601 link from the doctrinebot above to point to #5109 which is where another discussion regarding this topic started. Interestingly #5109 (aka DDC-601) was flagged "Improvement" instead of "Won't fix" or "Can't fix" which I think is the right thing. |
Really didn't mean to be rude, sorry! I'm changing statuses there - most probably was already labeled incorrectly before importing from Jira. |
No problem. The meaning of a text message can be way more misleading than actually hearing someone saying it. And thanks for all the re-labeling. |
I'm getting error in Symfony 3.3 I'm simply trying to call $this->om->remove($entry); and getting an SQL error for INSERT despite the fact that I'm not trying to insert anything, just remove. It looks like it's trying to set a field to null and then failing on an integrity constraint. The field in question is not null when the entity entry is loaded using find, but when remove is called somehow that field in question is set to null. EDIT: Ended up doing this as a workaround $queryBuilder = $this->repository->getQueryBuilder();
$queryBuilder
->delete()
->where('qb.id = :id')
->setParameter('id', $id)
->getQuery()
->getResult(); |
I had the same issue. I solved the problem by calling $em->remove($child);
$em->remove($parent);
$em->flush(); |
There are a few requests (doctrine#5742, doctrine#5368, doctrine#5109, doctrine#6776) that ask to change the order of operations in the UnitOfWork to perform "deletes before inserts", or where such a switch appears to solve a reported problem. I don't want to say that this is not doable. But this PR at least adds two tricky examples where INSERTs need to be done before an UPDATE can refer to new database rows; and where the UPDATE needs to happen to release foreign key references to other entities before those can be DELETEd. So, at least as long as all operations of a certain type are to be executed in blocks, this example allows no other order of operations than the current one.
There are a few requests (doctrine#5742, doctrine#5368, doctrine#5109, doctrine#6776) that ask to change the order of operations in the UnitOfWork to perform "deletes before inserts", or where such a switch appears to solve a reported problem. I don't want to say that this is not doable. But this PR at least adds two tricky examples where INSERTs need to be done before an UPDATE can refer to new database rows; and where the UPDATE needs to happen to release foreign key references to other entities before those can be DELETEd. So, at least as long as all operations of a certain type are to be executed in blocks, this example allows no other order of operations than the current one.
Jira issue originally created by user drauschenbach:
Steps to reproduce:
Expected result:
A DELETE followed by an INSERT
Actual result:
An INSERT with a new assigned primary key, but a failure on some other unique index
The text was updated successfully, but these errors were encountered: