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.

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.

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

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.

This pull request was closed due to inactivity.