0
public abstract class Base {
    public Guid Id { get;set; }
    public Navigation Nav { get;set; }
    public string NavID { get;set; }
}

public class ConcreteFirst: Base { }

public class ConcreteSecond: Base { }

public class Navigation Nav {
    public string NavID { get; set; }
    public ICollection<ConcreteFirst> ConcreteFirsts { get;set; }
    public ICollection<ConcreteSecond> ConcreteSeconds { get;set; }
}

//OnModelCreating
builder.Entity<Base>().Ignore(b => b.Nav);

builder.Entity<ConcreteFirst>()
       .HasOne(c => c.Nav)
       .WithMany(n => n.ConcreteFirsts)
       .HasForeignKey(c => c.NavID);

builder.Entity<ConcreteSecond>()
       .HasOne(c => c.Nav)
       .WithMany(n => n.ConcreteSeconds)
       .HasForeignKey(c => c.NavID);
//...
DbSet<Base> Bases { get; set;}
DbSet<ConcreteFirst> Firsts { get; set;}
DbSet<ConcreteSecond> Seconds { get; set;}
DbSet<Navigation> Navigations { get; set; }

There is error:

The foreign keys {NavID} on 'ConcreteSecond' and {'NavID'} on 'ConcreteFirst' are both mapped to FK_Bases_Navigations_NavID' but with different uniqueness

I guess it can be fixed of renaming either ConcreteFirst.Nav or ConcreteSecond.Nav property but it will cause of the increase of columns in Bases table. How can I resolve this issue with Nav name for both ConcreteFirst and ConcreteSecond?

Ilya Loskutov
  • 1,967
  • 2
  • 20
  • 34
  • Just a heads up there's some typos in what you posted I guess. ConcreteFirst member NavID has no type string. builder.Entity().WithMany(n => n.ConcreteFIRSTS) – pijemcolu Jun 29 '17 at 12:04
  • @pijemcolu fixed, thank – Ilya Loskutov Jun 29 '17 at 12:08
  • was it the typo in builder.entity? Should I post an asnwer or do you want to close this ? – pijemcolu Jun 29 '17 at 12:09
  • @pijemcolu it was some typo, yes. It's not issue of my answer – Ilya Loskutov Jun 29 '17 at 12:11
  • What if you also ignore `NavID` for the base class? Point is, `Nav` and `NavID` would typically belong to both of the deriving classes separately, so writing them into the parent class only makes sense in the OO world, not in the SQL world... then again, TPH is a bit special, it might be possible to explicitely force EF to re-use the same column for the properties of multiple sub-classes (similar to this Q/A: https://stackoverflow.com/questions/19577453/entity-framework-6-tph-inheritance-map-properties-with-the-same-name-to-same) – grek40 Jun 29 '17 at 12:55
  • I've tried your sample and it works for me - no errors (EF Core v.1.1.2) – Ivan Stoev Jun 29 '17 at 14:08
  • Known bug. Fixed for next release. https://github.com/aspnet/EntityFramework/issues/7240 – Smit Jun 29 '17 at 19:03

1 Answers1

0

Entity Framework supports different inheritance strategies.

Table Per Hierarchy is the default one. So, by default, EF uses single table for both parent and it's children.

You can easely change this behavior. Just specify the table you wish to use:

builder.Entity<ConcreteFirst>()
    .ToTable("Firsts");
// ...
builder.Entity<ConcreteSecond>()
    .ToTable("Seconds");
// ...

If you would like to not even use a separate table for parent's properties, just don't register it and map these properties to the children tables like this:

builder.Entity<ConcreteFirst>().Map(m => {
    m.MapInheritedProperties();
    m.ToTable("Firsts");
    // ...
});
// ...

================

UPD:

EF Core behavior is a bit different. It, if you use ToTable method, will map all of the parent properties by default.

Fynivx
  • 101
  • 2