Delete behaviors
Delete behaviors are defined in the DeleteBehavior enumerator type and can be passed to the OnDelete fluent API to control whether the deletion of a principal/parent entity or the severing of the relationship to dependent/child entities should have a side effect on the dependent/child entities.
There are three actions EF can take when a principal/parent entity is deleted or the relationship to the child is severed:
- The child/dependent can be deleted
- The child‘s foreign key values can be set to null
- The child remains unchanged
Note The delete behavior configured in the EF Core model is only applied when the principal entity is deleted using EF Core and the dependent entities are loaded in memory (that is, for tracked dependents). A corresponding cascade behavior needs to be setup in the database to ensure data that is not being tracked by the context has the necessary action applied. If you use EF Core to create the database, this cascade behavior will be setup for you.
For the second action above, setting a foreign key value to null is not valid if foreign key is not nullable. (A non-nullable foreign key is equivalent to a required relationship.) In these cases, EF Core tracks that the foreign key property has been marked as null until SaveChanges is called, at which time an exception is thrown because the change cannot be persisted to the database. This is similar to getting a constraint violation from the database.
There are four delete behaviors, as listed in the tables below.
Optional relationships
For optional relationships (nullable foreign key，或者根本就没设置外键) it is possible to save a null foreign key value, which results in the following effects:
| Behavior Name | Effect on dependent/child in memory | Effect on dependent/child in database |
|---|---|---|
| Cascade | Entities are deleted | Entities are deleted |
| ClientSetNull (Default) | Foreign key properties are set to null | None |
| SetNull | Foreign key properties are set to null | Foreign key properties are set to null |
| Restrict | None | None |
Required relationships
For required relationships (non-nullable foreign key) it is not possible to save a null foreign key value, which results in the following effects:
| Behavior Name | Effect on dependent/child in memory | Effect on dependent/child in database |
|---|---|---|
| Cascade (Default) | Entities are deleted | Entities are deleted |
| ClientSetNull | SaveChanges throws | None |
| SetNull | SaveChanges throws | SaveChanges throws |
| Restrict | None | None |
In the tables above, None can result in a constraint violation. For example, if a principal/child entity is deleted but no action is taken to change the foreign key of a dependent/child, then the database will likely throw on SaveChanges due to a foreign constraint violation.
At a high level:
- If you have entities that cannot exist without a parent, and you want EF to take care for deleting the children automatically, then use Cascade.
- Entities that cannot exist without a parent usually make use of required relationships, for which Cascade is the default.
- If you have entities that may or may not have a parent, and you want EF to take care of nulling out the foreign key for you, then use ClientSetNull
- Entities that can exist without a parent usually make use of optional relationships, for which ClientSetNull is the default.
- If you want the database to also try to propagate null values to child foreign keys even when the child entity is not loaded, then use SetNull. However, note that the database must support this, and configuring the database like this can result in other restrictions, which in practice often makes this option impractical. This is why SetNull is not the default.
- If you don‘t want EF Core to ever delete an entity automatically or null out the foreign key automatically, then use Restrict. Note that this requires that your code keep child entities and their foreign key values in sync manually otherwise constraint exceptions will be thrown.
原文地址：https://www.cnblogs.com/OpenCoder/p/9819226.html