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

Add test to show why delete-before-insert may be challenging #10809

Merged
merged 1 commit into from
Jun 30, 2023

Conversation

mpdude
Copy link
Contributor

@mpdude mpdude commented Jun 28, 2023

There are a few requests (#5742, #5368, #5109, #6776, #7721, #7722, #2310) 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.

greg0ire
greg0ire previously approved these changes Jun 28, 2023
$this->createSchemaForModels(
GH5742Person::class,
GH5742Toothbrush::class,
GH5742ToothpasteBrand::class
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Aaaah a funny test at last… this is going to be good! 🍿

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I designed it that way particularly with you in mind 😉

$person->preferredBrands->set(1, $oldMice);
$this->_em->flush();

$newSpice = new GH5742ToothpasteBrand();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"old mice"? "new spice" What's the joke? I don't get it… 🤔

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Old mice 🐁 is not so yum.

New spice might me something fresh like peppermint?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense :)

@SenseException
Copy link
Member

What do we expect when those tests fail? An exception that breaks the tests?

@mpdude
Copy link
Contributor Author

mpdude commented Jun 29, 2023

Yes, something related to foreign keys, constraint violation and such

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 mpdude force-pushed the show-trouble-delete-before-insert branch from 0ecf3fe to e9b6fd8 Compare June 29, 2023 12:32
@greg0ire greg0ire requested a review from derrabus June 29, 2023 19:28
@greg0ire greg0ire added this to the 2.16.0 milestone Jun 30, 2023
@greg0ire greg0ire merged commit 8eb6992 into doctrine:2.16.x Jun 30, 2023
@greg0ire
Copy link
Member

Thanks @mpdude !

@mpdude mpdude deleted the show-trouble-delete-before-insert branch June 30, 2023 18:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants