A unique index only means an alternate key if it is the principal end of an FK #8089
Conversation
… the principal end of an FK.
| @@ -168,4 +168,7 @@ | |||
| <data name="MissingTable" xml:space="preserve"> | |||
| <value>Unable to find a table in the database matching the selected table {table}.</value> | |||
| </data> | |||
| <data name="ForeignKeyPrincipalEndContainsNullableColumns" xml:space="preserve"> | |||
| <value>The principal end of the foreign key '{foreignKeyName}' contains the following nullable columns '{columnNames}'. Entity Framework requires the properties representing those columns to be non-nullable.</value> | |||
| </data> | |||
There was a problem hiding this comment.
Forgot to mention the index here. I'll make it something like "The principal end of the foreign key '{foreignKeyName}' is supported by the unique index '{indexName}' and contains the following nullable columns '{columnNames}'...." and check in.
lajones
added
closed-fixed
|
Checked in with commit 439f510. |
|
Added |
|
We should avoid having PRs without proper merge. If we merge PR with fast forward then git marks it as merged PR and also stores reference to it while looking at commit. This makes it much easier to come back to PR from a commit at later stage if needed. |
|
@smitpatel we should talk about this offline. I just merged from the command-line (I did not specify the ff flag) and everything looks normal to me on |
Fixes issue #7956.
Previously a unique index implied that the properties on which that index is based would be set as required even if the underlying columns were nullable. Now we only do this if the properties are the principal end of a foreign key. This prevents columns which just happen to use a unique index but have nothing to do with a FK being set to required when this is not necessary.