Skip to content
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

Closed
doctrinebot opened this issue Oct 30, 2010 · 13 comments
Closed

DDC-847: EntityManager flush performs insert before remove #5368

doctrinebot opened this issue Oct 30, 2010 · 13 comments

Comments

@doctrinebot
Copy link

Jira issue originally created by user drauschenbach:

Steps to reproduce:

  1. Load an entity from an EntityManager (one with a generator=AUTO primary key)
  2. perform $em->remove(entity);
  3. Create a new entity to re-create it, using identical attributes (except for PK): $em->persist(new entity);
  4. flush()

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

@doctrinebot
Copy link
Author

Comment created by romanb:

This is not a bug. See DDC-601.

@doctrinebot
Copy link
Author

Issue was closed with resolution "Won't Fix"

@ureimers
Copy link
Contributor

ureimers commented Dec 2, 2016

Should it even possible to "solve" a bug with "Won't Fix"?

N.B.: DDC-601 is now here: #5109

@Ocramius
Copy link
Member

Ocramius commented Dec 2, 2016

@ureimers that's the wording from the JIRA import that we did last year.

@ureimers
Copy link
Contributor

ureimers commented Dec 2, 2016

I see. So it's no bug at all?

@Ocramius
Copy link
Member

Ocramius commented Dec 2, 2016

Intended behavior: lemme re-label.

@ureimers
Copy link
Contributor

ureimers commented Dec 2, 2016

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 setShouldPerformDeletesFirst or something similar.

Btw.: Did I just see the labels change while being on the page? Phew... technology today...

@Ocramius
Copy link
Member

Ocramius commented Dec 2, 2016

@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...

@ureimers
Copy link
Contributor

ureimers commented Dec 2, 2016

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.

@Ocramius
Copy link
Member

Ocramius commented Dec 2, 2016

And that's rude btw...

Really didn't mean to be rude, sorry!

I'm changing statuses there - most probably was already labeled incorrectly before importing from Jira.

@ureimers
Copy link
Contributor

ureimers commented Dec 2, 2016

Really didn't mean to be rude, sorry!

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.

@MatthewBooth
Copy link

MatthewBooth commented Sep 1, 2017

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();

@ruester
Copy link

ruester commented Apr 17, 2018

I had the same issue. I solved the problem by calling flush() later.
In my case there were entries that depend on each other. So if I deleted a depending entry doctrine wants to update the other entry which has a "foreign key not null" constraint (which of course fails).
So if I first detached both depending entries and then flush afterwards everything was fine:

$em->remove($child);
$em->remove($parent);
$em->flush();

mpdude added a commit to mpdude/doctrine2 that referenced this issue Jun 28, 2023
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.
mpdude added a commit to mpdude/doctrine2 that referenced this issue Jun 29, 2023
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants