Orm: DDC-847: EntityManager flush performs insert before remove

[doctrinebot]

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]

Comment created by romanb:

This is not a bug. See DDC-601.

[doctrinebot]

Issue was closed with resolution "Won't Fix"

[ureimers]

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

N.B.: DDC-601 is now here: https://github.com/doctrine/doctrine2/issues/5109

[Ocramius]

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

[ureimers]

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

[Ocramius]

Intended behavior: lemme re-label.

[ureimers]

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]

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

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]

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]

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]

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]

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