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

[Gh-8589] A new approach to non-nullable typed associations for BC #8678

Merged
merged 2 commits into from
May 10, 2021

Conversation

beberlei
Copy link
Member

@beberlei beberlei commented May 9, 2021

This partially reverts #8589 because it was overzealously working on non typed properties as well, defining 'nullable' => true on all join columns. This made CascadeRemoveOrderTest fail on databases with foreign keys.

With this approach the code about join columns stays untouched, unless the typed property is defined as non-nullable and join columns are used.

Fixes #8638

@beberlei
Copy link
Member Author

beberlei commented May 9, 2021

@Lustmored ping for a comment :-)

@beberlei beberlei added this to the 2.9.0 milestone May 9, 2021
Lustmored
Lustmored previously approved these changes May 10, 2021
Copy link
Contributor

@Lustmored Lustmored left a comment

Choose a reason for hiding this comment

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

It generally looks good and certainly solves the issue 👍 I was certain that nullable = true should be the default hence the regression.

I would just leave tests for targetEntity (per code comments) as they seem useful.

@beberlei beberlei merged commit e24b0f0 into doctrine:2.9.x May 10, 2021
@beberlei beberlei deleted the GH-8589-RevertNullableAssoc branch May 10, 2021 17:08
@rvanlaak
Copy link
Contributor

I have a question while trying to understand the scope of this PR, and whether we will wait on 2.9 to release or try helping by contributing a PR.

Could this PR somehow be related to the long-standing #4090 issue from 2014 on OneToOne relationships having their FK set to non-nullable?

In other words, is 2.9 going to allow the scenario that PR #6533 tried to solve earlier? 👏 If not, would there be anything to help, and/or could a fix get backported to make it in 2.8.x ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants