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 a test case to show #10348 has been fixed #10732

Merged
merged 1 commit into from
Jun 2, 2023

Conversation

mpdude
Copy link
Contributor

@mpdude mpdude commented May 31, 2023

This is part of the series of issues fixed by #10547. In particular, the changes from #10566 were relevant.

See #10348 for the bug description.

@mpdude mpdude changed the title Add a test case to show #10348 has been fixed by #10566 Add a test case to show #10348 has been fixed May 31, 2023
@mpdude mpdude force-pushed the 10348-fixed branch 2 times, most recently from 0a0e866 to 2307be9 Compare May 31, 2023 20:03
@mpdude
Copy link
Contributor Author

mpdude commented May 31, 2023

@greg0ire Thank you for the suggestion! That makes it a lot better.

I've re-checked that this test indeed fails on 2.16, so it shows the issue has been fixed.

However, I wonder how we could make the test a bit more "forcing" – that is, make it obvious that naturally the ORM would delete $person1 before $person2, and that it is a merit that it recognized the situation and turns things around.

Any ideas?

$this->_em->flush();

self::assertEmpty($this->_em->createQuery('SELECT c FROM ' . GH10348Company::class . ' c')->getResult());
self::assertEmpty($this->_em->createQuery('SELECT p FROM ' . GH10348Person::class . ' p')->getResult());
Copy link
Member

Choose a reason for hiding this comment

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

Are these assertions maybe superfluous and distracting? We're not testing the cascade here, are we? I think it would be best to remove them and use @doesNotPerformAssertions

Copy link
Contributor Author

Choose a reason for hiding this comment

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

In another test that we merged recently Claudio suggested to have a check like this instead of @doesNotPerformAssertions. After all, the query returning an emtpy result is the best indication of things actually happening (entities being deleted).

I'm indifferent – you decide.

Copy link
Member

Choose a reason for hiding this comment

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

I see, we're not only checking there is no crash, we are checking that the reason there is no crash isn't nothing actually happening. Kind of far-fetched because I would expect that to be fairly covered already, but who knows. Works for me I suppose.

This is part of the series of issues fixed by doctrine#10547. In particular, the changes from doctrine#10566 were relevant.

See doctrine#10348 for the bug description.

Co-authored-by: Grégoire Paris <postmaster@greg0ire.fr>
@greg0ire greg0ire merged commit b5595ca into doctrine:entity-level-commit-order Jun 2, 2023
@greg0ire
Copy link
Member

greg0ire commented Jun 2, 2023

Thanks @mpdude !

@mpdude mpdude deleted the 10348-fixed branch June 2, 2023 05:52
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.

3 participants