Relational: TPH inheritance mapping pattern

[rowanmiller]

No description provided.

[divega]

The highest priority is to support some form of table per hierarchy a.k.a single table inheritance.

[irperez]

+1 on the various mapping patterns (TPT, TPH, etc) Please don't forget a mix of the two in a single graph.

[kidchenko]

+1 for the inheritance support, at least one strategy.

[ErikEJ]

Please do NOT support mixing strategies...

[ilmax]

Please do not support inheritance OOB, can this be achieved in a separate package so to make pay for play real?

[kidchenko]

Since we do not support inheritance, what better alternative? I was thinking of creating a single class and put all the attributes in it, so work with a single table and a single class, simulating a strategy TPH

[irperez]

Without at least TPH, we cannot use EF. For simple applications, the above scenarios may be fine. But for very complex scenarios especially in a world of medical applications (my company develops medical software for cancer regimens), we would not be able to handle such simple scenarios.

[rowanmiller]

@Kiide & @irperez - This is just a limitation of the current pre-release versions of EF7. Pre-release are just designed for trying out EF7 so we definitely would not recommend using it to try and write real applications with.

[kidchenko]

Yes i uderstand

[phillip-haydon]

As part of EF 7, are you going to fix all the bugs that are currently in 6? Like mapping to the same foreign key for different relationships?

[rowanmiller]

Moving into 7.0.0 since we are in the process of enabling at least some scenarios at the moment.

[issafram]

For TPH, allow us to pick a custom Discriminator. There should be no reason to store a string field for each row. That is my biggest issue with TPH.

[anpete]

@issafram In EF7 you can pick any property for the discriminator.

[issafram]

@anpete will it support using enums for the discriminator?

[anpete]

@issafram Yes.

[weitzhandler]

Any workaround even temporary? Can's live with all subclasses being generated as separated tables.

Is there even a list to exclude base classes?

For instance I have TeacherBase and Teacher, and in fact don't want the TeacherBase at all as a table, I only need Teacher to be generated carrying all properties include the base class'.

[issafram]

@weitzhandler, did you try the NotMapped annotation?

Maybe you are asking for TPC (Table Per Concrete Type), but that can get confusing with foreign keys in other tables.

[weitzhandler]

I've opened a separate issue.
#2907

[divega]

@rowanmiller this item seems to represent the inheritance work as a whole and it is assigned to the 7.0.0 release. Should it have a priority and an owner or should we close it?

[rowanmiller]

Yep, changed title to reflect that we are implementing TPH for initial release (we have other issues on the backlog to track enabling other patterns).

Assigning to Andriy since he has the inheritance ball at the moment (for the model building work). We should keep this open until things work well end-to-end.

[leolana]

@ErikEJ because do NOT support mixing strategies ?

[jimmymain]

how is TPC inheritance being tracked?
I have an existing project where each class within the hierarchy is mapped to a particular table.
I will move this model over to version 7 once it's implemented. Is this strategy also being tracked by this issue 247. The title does not make this clear.

edit: I see this is being tracked as issue 2266, and is rediculously being debated as a feature.

[rowanmiller]

@jimmymain #2266 is actually for TPT, I opened #3170 to track TPC (they were originally all tracked by this issue, but then we split it out since we are only implementing TPH for the initial stable release)

[AndriySvyryd]

TPH is now fully implemented