Consider moving DeleteBehavior enum to core namespace #8632
Labels
breaking-change
closed-fixed
The issue has been fixed and is/will be included in the release indicated by the issue milestone.
type-enhancement
Milestone
Comments
ajcvickers
added a commit
that referenced
this issue
Jun 5, 2017
…and Restrict in the database Issues #8654, #8632, #8633 The new behavior is called 'ClientSetNull'. 'Restrict' now throws on SaveChanges if EF would have set null. This is the same behavior that has always been there for required relationships, so this is only a break for optional relationships explicitly configured with Restrict, which should be relatively rare since this was the default anyway. The default is now 'ClientSetNull', which matches the old behavior of 'Restrict', so apps that were not setting anything explicitly will not get a breaking change.
ajcvickers
added a commit
that referenced
this issue
Jun 5, 2017
…and Restrict in the database Issues #8654, #8632, #8633 The new behavior is called 'ClientSetNull'. 'Restrict' now throws on SaveChanges if EF would have set null. This is the same behavior that has always been there for required relationships, so this is only a break for optional relationships explicitly configured with Restrict, which should be relatively rare since this was the default anyway. The default is now 'ClientSetNull', which matches the old behavior of 'Restrict', so apps that were not setting anything explicitly will not get a breaking change.
ajcvickers
added a commit
that referenced
this issue
Jun 5, 2017
…and Restrict in the database Issues #8654, #8632, #8633 The new behavior is called 'ClientSetNull'. 'Restrict' now throws on SaveChanges if EF would have set null. This is the same behavior that has always been there for required relationships, so this is only a break for optional relationships explicitly configured with Restrict, which should be relatively rare since this was the default anyway. The default is now 'ClientSetNull', which matches the old behavior of 'Restrict', so apps that were not setting anything explicitly will not get a breaking change.
ajcvickers
added a commit
that referenced
this issue
Jun 6, 2017
…and Restrict in the database Issues #8654, #8632, #8633 The new behavior is called 'ClientSetNull'. 'Restrict' now throws on SaveChanges if EF would have set null. This is the same behavior that has always been there for required relationships, so this is only a break for optional relationships explicitly configured with Restrict, which should be relatively rare since this was the default anyway. The default is now 'ClientSetNull', which matches the old behavior of 'Restrict', so apps that were not setting anything explicitly will not get a breaking change.
ajcvickers
added
the
closed-fixed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
(I hit this while writing some code today. Not sure if there are other similar cases.)
The fact that you have to bring the 'Microsoft.EntityFrameworkCore.Metadata' in order to resolve the argument of a pretty standard
OnDelete()fluent API IMO hinders usability.I would expect the negative impact of a change like this in 2.0 to be low.
The text was updated successfully, but these errors were encountered: