Hi,
I was using EF5 and decided to switch to EF6.
If you run the attached project, you will find that the TPT inheritance is not properly applied to the database, but only for foreign keys. In this example the Department_Id foreign key is moved up to the Person table instead of being in the Employee table, while the HiredDate field remains in the Employee table.
Removing the Clients property from the DB context, or simply reverting to EF5 restores the proper behavior.
You need to add the EF6 rc1 package to the attached project in order for it to run and to reproduce the bug. It uses localdb v11.0 as its database.
Comments: @dismuter - Understood, we typically just use High for ship stopping bugs. This one is probably border line High/Medium as it is a regression - but not one that the majority of developers will hit. All that to say - we agree this is an important bug to fix. Because there are a number of other products that depend on EF6 (ASP.NET, Visual Studio, etc.) we have to lock EF down pretty early in the release cycle when we do a combined release (which EF6 is). For that reason we are only taking ship stopping bugs at this stage. So were planning to fix this one in the next patch/minor release after EF6.
I was using EF5 and decided to switch to EF6.
If you run the attached project, you will find that the TPT inheritance is not properly applied to the database, but only for foreign keys. In this example the Department_Id foreign key is moved up to the Person table instead of being in the Employee table, while the HiredDate field remains in the Employee table.
Removing the Clients property from the DB context, or simply reverting to EF5 restores the proper behavior.
You need to add the EF6 rc1 package to the attached project in order for it to run and to reproduce the bug. It uses localdb v11.0 as its database.
Comments: @dismuter - Understood, we typically just use High for ship stopping bugs. This one is probably border line High/Medium as it is a regression - but not one that the majority of developers will hit. All that to say - we agree this is an important bug to fix. Because there are a number of other products that depend on EF6 (ASP.NET, Visual Studio, etc.) we have to lock EF down pretty early in the release cycle when we do a combined release (which EF6 is). For that reason we are only taking ship stopping bugs at this stage. So were planning to fix this one in the next patch/minor release after EF6.