-
Notifications
You must be signed in to change notification settings - Fork 3.2k
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
Shadow FK created by replicating the property type from principal key are non-nullable #4895
Comments
Small observation: If the property name matches by convention then |
Same test results with following models too. public class BloggingContext : DbContext
{
public DbSet<Post> Posts { get; set; }
protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
{
optionsBuilder.UseInMemoryDatabase();
}
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
modelBuilder.Entity<Post>(b =>
{
b.HasOne(e => e.PostedBy).WithMany().HasForeignKey("AuthorId");
b.HasOne(e => e.ModifiedBy).WithMany().HasForeignKey("ModifiedById");
});
}
}
public class Post
{
public int PostId { get; set; }
public string Body { get; set; }
public User PostedBy { get; set; }
public User ModifiedBy { get; set; }
}
public class User
{
public int Id { get; set; }
public string Name { get; set; }
} |
Found the issue |
@AndriySvyryd - Should we just use nullable type while copying from principal key? 😄 |
@smitpatel Yes, by default FKs are not required and thus should create nullable shadow properties |
I tried applying
[ForeignKey(name)]
on a reference navigation property that didn't have a corresponding FK property in the CLR type to pick a column name that was different from the one that the convention would produce.This had the unexpected side effect that it made the FK non-nullable (which in turns activated cascade deletes, caused queries with
Include()
on that navigation property to translate to INNER JOINs, etc).None of these things happened if the name I specified in the attribute matched what the convention would pick.
I haven't dug into the implementation but I wonder if this affects more than just the nullability of the property, and if the relationship builder should produce nullable FKs by default.
Repro
The text was updated successfully, but these errors were encountered: