Relational: TPC inheritance mapping pattern

[rowanmiller]

Consider configuring or issuing a warning to help with split identity seeding or shared sequence for the PK
FKs that point to a TPC entity type won't be enforced

• Model support
• Migrations support
• Seed data support
• SaveChanges support
• Query support
• End-to-end tests

Related: #17270 (comment)

[wangkanai]

Can I make assumption that TPC is now going to be in RC? judged by the following work as expected

public class Program
{
    public void Main(string[] args)
    {
        var context = new InheritanceContext();
        var sarin = new Manager() {Name = "Sarin"};
        var siriphan = new Employee() {Name = "Siriphan", Manager = sarin};
        context.Managers.Add(sarin);
        context.Employees.Add(siriphan);
        context.SaveChanges();
    }
}

public class InheritanceContext : DbContext
{
    public DbSet<Manager> Managers { get; set; }
    public DbSet<Employee> Employees { get; set; }
    protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
    {
        optionsBuilder.UseSqlServer(@"Server=(localdb)\MSSQLLocalDB;Database=Ef7Inheritance;Trusted_Connection=True;");
    }
}

public class Person
{
    public int Id { get; set; }
    public string Name { get; set; }
}

public class Manager : Person
{
    public Collection<Employee> Staffs { get; set; } 
}

public class Employee : Person
{
    public Manager Manager { get; set; }
}

This code is tested EntityFramework 7.0.0-beta8

[jimmymain]

awesome!

[rowanmiller]

@wangkanai you are really just getting two separate entity types with an unmapped base type. They each have a separate key space and you won't be able to run a LINQ query on Person. So it's not really inheritance in EF, it's two separate entity types that happen to share a base type in the CLR for implementation.

[wangkanai]

If their are in same key space would that work well with sql server auto incremental primary key?

[rowanmiller]

@wangkanai not with Identity (since that is per table) but you could use a sequence to generate values. What I really meant is that with true TPC you can't have Manager with Id = 1 and an Employee with Id = 1 since then you would have two instances of Person with Id = 1 (and EF would throw if you every tried to have this). In you setup this is possible since they aren't really in an inheritance hierarchy as far as EF is concerned.

[wangkanai]

@rowanmiller so if in theory we make a convention to use Id as identity key as Guid (in theory it unique), this should work right?

[weitzhandler]

I'd wanna see TPT before TPC. As @rowanmiller said, @wangkanai example will be used in rare cases when you explicitly wanna keep the entities unmapped or whatever other reason I can't think of now.
But TPT is even more important than TPH, because it can save a bunch of columns generated in each table completely DRYed and less-productive for some purposes.
Lack of TPC made me start a new project in MVC5 and give up the new beta.
Will this be implemented for the RC?

[rowanmiller]

@wangkanai yep that would work. Just to be clear though... with the code you listed back at the start there is no need to ensure that the keys are unique between types since EF is treating them as completely separate types. But for true TPC, yes GUID keys is one option, or a sequence for numeric values, etc.