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

Adding a test case indicating that certain scenarios involving one-to… #7722

Closed
wants to merge 1 commit into from

Conversation

LukasKrc
Copy link

@LukasKrc LukasKrc commented May 24, 2019

…-one relations cause unique index errors.

#7721

@beberlei
Copy link
Member

beberlei commented Dec 1, 2019

Preliminary findings and potential fix approach:

  1. yes this bug always existed, we usually recommend double flush before (sucks yeah).
  2. problem here is mysql checking unique constraints every row, not during commit: https://dev.mysql.com/doc/refman/5.7/en/innodb-foreign-key-constraints.html
  3. solution would need to have a flag on AbstractPlatform (supportsDeferredUniqueProcessingDuringCommit()). I believe Postgresql does it that way.
  4. If deferred unique processing not supported, then for a bidirectional one to one, computeChangeSet should detect the change and schedule an extra update to set the foreign key empty.

@lcobucci lcobucci self-requested a review December 3, 2019 08:26
@lcobucci
Copy link
Member

lcobucci commented Dec 3, 2019

  1. solution would need to have a flag on AbstractPlatform (supportsDeferredUniqueProcessingDuringCommit()). I believe Postgresql does it that way.
  2. If deferred unique processing not supported, then for a bidirectional one to one, computeChangeSet should detect the change and schedule an extra update to set the foreign key empty.

That's quite correct but I think we can only add the support for deferred stuff in v2.8.0 (since that would require a bump on DBAL).

It would be awesome if we could solve the update/delete during computeChangeSet but I'm not sure if that's feasible since both updates and deletes are processed afterwards in UoW#commit().
What we could do (in v2.7.1) is try to handle this similar to how collection deletes are treated (as in pulling the deletion before of the insertion).

Base automatically changed from master to old-prototype-3.x February 23, 2021 08:19
Copy link
Contributor

There hasn't been any activity on this pull request in the past 90 days, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 7 days.
If you want to continue working on it, please leave a comment.

@github-actions github-actions bot added the Stale label Dec 18, 2024
Copy link
Contributor

This pull request was closed due to inactivity.

@github-actions github-actions bot closed this Dec 28, 2024
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