EF Core uses a "foreign key" property that is matched to a "principal key" to define a relationship, where one or both of these may be shadow properties. For relational databases, these relationships are almost always backed by a constraint which means that if an FK property has a value, then there must exist a principal key that matches. We use this information to make decisions/optimizations on which queries to generate. In #9470, we decided to maintain these semantics across providers.
However, there are some cases where the FK and PK exist and define the relationship, but are not constrained in the same way as a relational constraint would do. Specifically, this means that just because an FK property has a value doesn't mean that there is necessarily a matching PK value. This means:
- the relationship is always optional, even if the FK isn't nullable
- we can't assume that because the FK is set that it means a principal must exist in the database
- and therefore we can't assume that getting all the principals will bring in all dependents (same as for optional relationships today)
- fixup needs to decide what to do if a relationship is severed but the FK is non-nullable
EF Core uses a "foreign key" property that is matched to a "principal key" to define a relationship, where one or both of these may be shadow properties. For relational databases, these relationships are almost always backed by a constraint which means that if an FK property has a value, then there must exist a principal key that matches. We use this information to make decisions/optimizations on which queries to generate. In #9470, we decided to maintain these semantics across providers.
However, there are some cases where the FK and PK exist and define the relationship, but are not constrained in the same way as a relational constraint would do. Specifically, this means that just because an FK property has a value doesn't mean that there is necessarily a matching PK value. This means: