Dissalow defining FKs on properties that are part of an inherited key

[AndriySvyryd]

Consider this model:

private class Burger
{
    public int Id { get; set; }
    public Bun Bun { get; set; }
}

private class Ingredient
{
    public int Id { get; set; }
}

private class Bun : Ingredient
{
    public Burger Burger { get; set; }
}

There's an FK from Bun.Id to Burger.Id, however there are no FKs defined from Ingredient. Should Ingredient.Id use its own value generator? Should it use value generator from Burger.Id? What if there's another type derived from Ingredient and it has an FK from Id to a different property? Should we prohibit defining FKs on properties that are part of an inherited key?.

[AndriySvyryd]

@ajcvickers

[rowanmiller]

@AndriySvyryd do we automatically wire up Bun.Id as the FK? Pretty sure we wouldn't have matched that in EF6?

[rowanmiller]

Should we prohibit defining FKs on properties that are part of an inherited key?.

Triage: We agree this sounds reasonable

[smitpatel]

@AndriySvyryd - This would require changes only in ForeignKeyPropertyDiscoveryConvention where searching for candidate fk properties (or compatible pk properties), properties which are part of inherited key won't be matched, right?

[AndriySvyryd]

@smitpatel We should throw in Entity.AddForeignKey()
We should also modify InternalEntityTypeBuilder.HasBaseType() to detect if the new base key conflicts with an fk and try to remove one of them if they do.

[HappyNomad]

How does this issue relate to EF Core's current codebase? On the one hand, when feeding in my large domain model, I get the exception, "The property 'ID' cannot be part of a foreign key on 'T' because it is contained in a key defined on a base entity type." On the other hand, while trying to understand what this exception means and how to fix it, I tested this issue's original comment's code. I expected it to fail with said exception, but it doesn't.

The data context contains these members:

public DbSet<Burger> Burgers { get; set; }
public DbSet<Ingredient> Ingredients { get; set; }
public DbSet<Bun> Buns { get; set; }

protected override void OnModelCreating( ModelBuilder modelBuilder )
{
    modelBuilder.Entity<Burger>()
        .HasOne( p => p.Bun )
        .WithOne( i => i.Burger )
        .HasForeignKey<Bun>( b => b.BurgerForeignKey );
}

And the model consists of these classes:

public class Burger
{
    public int Id { get; set; }
    public Bun Bun { get; set; }
}

public class Ingredient
{
    public int Id { get; set; }
}

public class Bun : Ingredient
{
    public Burger Burger { get; set; }
    public int BurgerForeignKey { get; set; }
}

And it works! That's weird since I'm still encountering the aforementioned exception when I feed in my more complex model.

[AndriySvyryd]

@HappyNomad That's not the code described in the first post. You need to configure it like this to get the exception:

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    modelBuilder.Entity<Burger>()
        .HasOne(p => p.Bun)
        .WithOne(i => i.Burger)
        .HasForeignKey<Bun>(b => b.Id);
}

[HappyNomad]

@AndriySvyryd Thank you for the correction. Sorry, but I still don't understand why this exception is necessary and how to avoid it. As you see in #6792, I have a model in which this exception is an issue. Although, there's a strange workaround in that small example (but not in my real domain model) that involves renaming a property.

Is the exception necessary due to either (a) a limitation of TPH mapping in general, or (b) the current EF core implementation specifically? I do not know EF Core's implementation, but I am generally familiar with relational databases and TPH mapping.

I do not understand the issue regarding value generation. Please explain the problem more completely, and further illustrate the scenario you are trying to avoid by throwing the exception.