Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Relational: TPT inheritance mapping pattern #2266

Open
satyajit-behera opened this issue May 24, 2015 · 181 comments

Comments

Projects
None yet
@satyajit-behera
Copy link

commented May 24, 2015

Even if TPT is considered slow, it is a boon for many real world business scenarios. If implemented properly and well thought of, TPT is not slow for a given need in most of the cases.

If possible, optimization can be done to TPT.
But its a very important feature for EF to be accepted for developing DDD applications.

The other method, Composition over Inheritance does not look viable since we cannot use interface property to create our model. Binding to a concrete type takes away the flexibility to customize the models. TPT makes the customization very easy and flexible.

@rowanmiller rowanmiller added this to the Backlog milestone May 29, 2015

@rowanmiller

This comment has been minimized.

Copy link
Member

commented May 29, 2015

Update: we are planning to implement TPT. This comment is from 2015. Please read the rest of the thread, not just this comment.

The feeling from our team is that TPT is generally an anti-pattern and results in significant performance issues later on. While enabling it may make some folks "happier" to start with it ultimately just leads to issues. We are willing to consider it though, so we're leaving this open and will consider it based on the feedback we get.

@satyajit-behera

This comment has been minimized.

Copy link
Author

commented May 29, 2015

Thanks. Issue is the absence of any alternative to build an OO application. Even Composition using interfaces does not look viable for now.

@rowanmiller

This comment has been minimized.

Copy link
Member

commented May 29, 2015

We are in the process of implementing TPH at the moment, so you will be able to persist an inheritance hierarchy to a single table in the near future.

@satyajit-behera

This comment has been minimized.

Copy link
Author

commented May 29, 2015

But it does not solve the main issue of extending a table. TPT becomes a necessity in practical business scenario. Otherwise, it may become a table with 100s of fields in it.

@anpete

This comment has been minimized.

Copy link

commented May 29, 2015

@satyajit-behera TPT is an inheritance mapping pattern. Are you referring to "Entity Splitting". i.e. Having a single entity mapped to more than one table?

@satyajit-behera

This comment has been minimized.

Copy link
Author

commented May 30, 2015

@anpete I am referring to One table per inherited entity type.

@GSPP

This comment has been minimized.

Copy link

commented Jun 15, 2015

TPT can be important for performance. Think of huge tables. Usually, you want only the absolutely required fields in such a table. TPH has column bloat, TPT is lean. Also, with TPT database statistics can be specialized for each type. This is important because different types can have vastly different data distributions.

TPT is quite an important pattern and I don't see why it would be considered an anti-pattern. An anti-pattern is a thing that is almost always the wrong choice. This does not seem to hold here.

@santanaguy

This comment has been minimized.

Copy link

commented Jun 23, 2015

@GSPP i agree with you. Having TPT is a must for an ORM and i think it was recurrent solution for a lot of problems in EF6 in the real world. I used it in my models a lot. One should be careful with the tools he uses, but that doesn't mean he shouldn't have those tools available. Both types of inheritance should be present in EF Core. Please include this scenario in the 7.0 release

@satyajit-behera

This comment has been minimized.

Copy link
Author

commented Jul 3, 2015

@rowanmiller I hope you will prioritize and include the TPT inheritance mapping for EF 7. All of us can discuss if some specific feature make it slow and get a workaround for the same. But the feature itself is very useful in business applications. Please include this in EF Core release. Thanks a lot.

@ToddThomson

This comment has been minimized.

Copy link

commented Jul 16, 2015

👍 TPT inheritance may have some performance issues, but the design clarity it provides for real world scenarios outweighs them. I also do not feel that TPT inheritance is an "anti-pattern".

@konstantin999

This comment has been minimized.

Copy link

commented Jul 31, 2015

@rowanmiller TPT inheritance is the reason why we can not use EF in our projects :( It would be nice if it will included in EF Core.
http://data.uservoice.com/forums/72025-entity-framework-feature-suggestions/suggestions/1015337-tpt-table-per-type-inheritance-performance
https://entityframework.codeplex.com/workitem/2332

@konstantin999

This comment has been minimized.

Copy link

commented Jul 31, 2015

For example, in DO this problem was solved by including a TypeId field in all types. http://help.x-tensive.com/Default.aspx##DataObjects.Net%20v3.9/html/P_DataObjects_NET_DataObject_TypeID.htm

@AndyNewland

This comment has been minimized.

Copy link

commented Aug 27, 2015

Agree 100% with @ToddThomson. This is another strong vote to add this feature ASAP. I think that TPH can be viewed as a SQL Server anti-pattern once the number of columns becomes unmanageable from a statistics and (more importantly) indexing viewpoint.

@satyajit-behera

This comment has been minimized.

Copy link
Author

commented Aug 27, 2015

@rowanmiller Hi, now you can consider including this feature asap. There is really no alternative to this to model real world objects in business application.

@jimmymain

This comment has been minimized.

Copy link

commented Sep 18, 2015

I agree with andy, if the EF team honestly believe that they cannot do this because it's too slow, we would have to look to alternate products. Entity framework becomes pretty useless for our real world business scenarios. Our SQL team will never endorse de-normalised tables because of EF.

I think some evidence is necessary before labeling this an anti pattern.

@ToddThomson

This comment has been minimized.

Copy link

commented Sep 18, 2015

Preface: This is not a knock against the EF Core team and their design goals. I really just want to know what I'm going to be working with if I choose to go with EF Core over EF6 for the next 12 months or so.

I think that there are real world scenarios that benefit from either TPH, TPC or TPT inheritance. I feel that the EF Core team needs to state clearly that TPC and/or TPT are going to be part of the future EF Core implementation or perhaps only to make some people happier down the road given enough community votes and when time permits. If TPC or TPT inheritance is not a high priority ( implementation if any, most likely later in 2016 ), then composition is the most likely alternative for those who want a normalized database schema.

For me personally, I believe moving to ASP.NET Core and EF Core is a port of my MVC 5, EF 6 application and I am willing to try different approaches. If I can't get EF Core to work then EF6 is still an option ( although the ASP.NET 5 Identity package requires EF Core and EF 6 code first migrations are issues ).

@rowanmiller rowanmiller changed the title TPT for EF7 Relational: TPT inheritance mapping pattern Sep 18, 2015

@jimmymain

This comment has been minimized.

Copy link

commented Sep 18, 2015

A clear statement of intent would assist us in making sound decisions on behalf of our clients.

@rowanmiller

This comment has been minimized.

Copy link
Member

commented Sep 28, 2015

TPT is definitely out for our November RC release (purely due to time constraints). Clearing up milestone so that we can re-discuss in triage and see if we can make a clear yes/no on our intent to support the feature in the future (my feeling is that we have enough feedback that folks want it).

@rowanmiller rowanmiller removed this from the Backlog milestone Sep 28, 2015

@ToddThomson

This comment has been minimized.

Copy link

commented Sep 28, 2015

Thank-you for the feedback @rowanmiller .

@satyajit-behera

This comment has been minimized.

Copy link
Author

commented Sep 29, 2015

Thanks @rowanmiller . Hope you will take this item with priority, since an alternative is not available to implement the concepts possible with TPT. Critical and Important. I am sure many enterprise level applications will be using this.

@thomas-darling

This comment has been minimized.

Copy link

commented Sep 29, 2015

Another vote for TPC and TPH - we absolutely need it and will look for another ORM if it's not supported. I agree that query performance is not great, but it is very important if we want a nicely normalized domain model. We can always create denormalized tables or views optimized for specific queries, but our single source of truth must be nicely structured.

The fact that inexperienced developers tend to abuse a feature, that does not mean the feature is not a criitical requirement for those of us who know what we are doing. It just means that people should learn about their tools before using them and that documentation should be improved to clearly state performance characteristics.

@rowanmiller

This comment has been minimized.

Copy link
Member

commented Sep 29, 2015

@thomas-darling TPH is already being implemented for our RC release in November (it mostly works now) and TPC is on our backlog (#3170). This issue is specifically about TPT and whether that pattern needs to be supported.

@satyajit-behera

This comment has been minimized.

Copy link
Author

commented Sep 29, 2015

@rowanmiller Difficult to get rid of TPT without any alternative implementation for the same. One common "Id" shared across all inherited classes. Base class should allow typecasting to inherited class. And all reside in different tables.

@rowanmiller rowanmiller added this to the Backlog milestone Oct 2, 2015

@AlonCG

This comment has been minimized.

Copy link

commented Nov 13, 2018

@ajcvickers Thanks for the response and I do appreciate what you (and your team) accomplishes. As well as your openness and honesty.

I do understand that EF 6 and EF Core are different products and the recommended guidance for using which one at which time. Initially the guidance was to use EF 6 if we needed a feature that was not implemented in Core. Had I thought initially that TPT in EF Core would keep getting booted down the line, I could have possibly removed any dependencies on EF 6 then and work around our usages of TPT.

While I understand not bringing TPT to EF Core is not in the plan ... I really have not seen any serious movement from the Microsoft side (other than possibly your commitment) to really take this request into consideration. (Just read the comments, "anti-pattern"!) Given the following scenario that (it appears to be that):

Dependencies on EF 6 are keeping projects similar to mine from migrating to Dot Net Core.

Once EF 6 gets ported to Dot Net Core 3.0, what stimulus does Microsoft then have to implement TPT in EF Core? (This is what I was trying to ask in my initial "rant".) By then another year or so would have passed and a new discussion may arise such as .. ."why should I be using 4+ yr old tech in my application?"

I do hope to be proved wrong and again, thanks for all the work you and your team does accomplish!

@ajcvickers

This comment has been minimized.

Copy link
Member

commented Nov 13, 2018

@AlonCG I understand your concerns. First, on TPT itself, there is a feeling among some that this is an anti-pattern, and earlier in the evolution of EF Core there was a desire for it to be more "opinionated" than EF6 and possibly more aligned to greenfield projects where the structure of the database was not already fixed. However, for at least the last couple of years we have acknowledged that there is significant demand for this kind of mapping and that we should support it in EF Core. This is somewhat like lazy-loading, which is supported in EF Core even though many people believe it is an anti-pattern precisely because many other people do not believe this and want to use it. So on the team we are committed to TPT, and we discuss it quite frequently.

With regard to why we would invest in TPT if EF6 runs on Core, the answer is that because EF6 still has all the limitations and baggage that caused us to start work on what became EF Core in the first place. For example, value/type conversions (which don't align well with the rigid EDM type system) are coming along very nicely in EF Core--there are still some issues in SQL translation, but generally they are working well and are opening up many scenarios on EF Core that are not possible on EF6. Going forward the gap between what EF6 can do and what EF Core can do will only get bigger, and telling people to use EF6 if they need TPT won't cut it because then they won't get all the other stuff they need in EF Core.

All that being said, whenever we talk about anything beyond the next release, and certainly when we're talking a year or two out it is important to remember that things can change. Strategic shifts and even tactical changes could result in changes in investment and/or priorities. However, right now I get the clear impression from management that there will be continued investment in EF Core going forward, and that TPT will be part of that.

@tjad

This comment has been minimized.

Copy link

commented Dec 13, 2018

Bump - this is important!

@ajcvickers Glad that TPT is being considered - hope it makes the next release!

EFCore is opinionated in that it persistently only presents 1 option as a strategy despite demand that is acknowledged for an alternative strategy.

TPT being an anti-pattern is an opinion, and that opinion may be valid in some scenarios.
Applying TPT to avoid sparse tables as a strategy is effective and provides application performance gains. Joins aren't an issue at all in context of this strategy or for database technology today. In context of the data model complexity we create today, this certainly counts heavily against EFCore as a choice of ORM for many applications.

And yes, I do acknowledge TPH is a good default strategy.

@tjad

This comment has been minimized.

Copy link

commented Dec 13, 2018

Do we have any PRs for this ? Is there an understanding of what's required to be done that can be shared to get more involvement on this?

@tjad

This comment has been minimized.

Copy link

commented Dec 13, 2018

And here's a workaround to at least achieve the correct database structure using a compositional coding style.

https://weblogs.thinktecture.com/pawel/2018/05/entity-framework-core-inheritance-tpt-is-not-supported-is-it-part-1-code-first.html

Note: Ideally we'd have native support.

@otabekgb

This comment has been minimized.

Copy link

commented Jan 10, 2019

Is TPT an anti-pattern??? TPH maybe, in a medium to large project, it gets messy.
Performance definitely is not a real issue since IDs will be indexed.
I hope this issue gets a milestone assigned soon, please. For most it is probably the cause not to choose EF, look at the reactions.

@insylogo

This comment has been minimized.

Copy link

commented Jan 24, 2019

Between this missing feature and no WCF services, I don't see why Microsoft expects anyone to migrate to .NET Core. Database normalization is not an "anti-pattern".

If I were in charge over there, I wouldn't even allow anyone to touch a document database while they still haven't implemented relational functionality for this ORM. That this issue isn't on the roadmap is a major clue to everyone not to adopt Core.

@tjad tjad referenced this issue Jan 25, 2019

Closed

TPT NOW! #14516

@bproven

This comment has been minimized.

Copy link

commented Jan 25, 2019

One of the main issues stopping us from migrating to Core.

@tcfialho

This comment has been minimized.

Copy link

commented Jan 29, 2019

The feeling from our team is that TPT is generally an anti-pattern and results in significant performance issues later on. While enabling it may make some folks "happier" to start with it ultimately just leads to issues. We are willing to consider it though, so we're leaving this open and will consider it based on the feedback we get.

"Good pattern" for EF Core team is many-to-many with "join entity class" workaround. LOL

@ajcvickers

This comment has been minimized.

Copy link
Member

commented Jan 29, 2019

I've updated the comment from 2015 to indicate that this no longer represents the feeling of the team.

@pantonis

This comment has been minimized.

Copy link

commented Feb 17, 2019

@ajcvickers Any estimate on this? Crucial, critical super important missing feature.

@ShahroozAnsari

This comment has been minimized.

Copy link

commented Feb 26, 2019

We need this feature asap.

@chrisdpratt

This comment has been minimized.

Copy link

commented Mar 5, 2019

Where on the roadmap is this feature currently? It's frankly beyond belief that as we're rolling up to EF Core 3.0, something as basic as TPT inheritance still isn't supported. I understand that it's a small team and you have many priorities, but honestly, lazy-loading, as just one example, should have taken a backseat to this.

@Bailoni

This comment has been minimized.

Copy link

commented Mar 11, 2019

@rowanmiller
okay? we are starting a project and wanted to start with EF Core, but I'm concerned that I do not have TPT support, a requirement in my company, can you tell the version or an estimated deadline for this release?

@ajcvickers

This comment has been minimized.

Copy link
Member

commented Mar 11, 2019

@Bailoni If I had to make my best guess right now, I'd say there is a reasonable chance it will get done in the next major version--that is 4.0. It's unlikely to get done before because we think some breaking changes, especially to database providers will be needed, as well as it being a major feature for a small team to take on. However, since 4.0 isn't planned yet and has no date it's hard to know for sure where things will be at or whether TPT will be included.

@insylogo

This comment has been minimized.

Copy link

commented Mar 11, 2019

Pretty funny. The second version of Entity Framework from 10 years ago had table-per-type normalization.

@weitzhandler

This comment has been minimized.

Copy link
Contributor

commented Mar 11, 2019

😢

@antoinebj

This comment has been minimized.

Copy link

commented Mar 11, 2019

@ajcvickers

as well as it being a major feature for a small team to take on.

Does Microsoft not have enough budget to get the team to the appropriate size? It's starting to look like the original EF development had a higher velocity and more investment put into it.
It's kind of sad to see this issue go way back to nearly 4 years ago and reading the comments getting more and more caustic about this feature being first called an anti-pattern and then just pushed back indefinitely. And there are so many other interesting things in the backlog. It must be overwhelming for a small team, I really hope you're able to cope.

@chrisdpratt

This comment has been minimized.

Copy link

commented Mar 11, 2019

@antoinebj I was thinking the same thing. EF hasn't seen any major advancement since EF Core came on the scene, and while .NET Core 3.0 will natively support EF6, you can't use it with ASP.NET Core without going the .NET Framework route currently. Even then, EF6 doesn't support certain important things like connection pooling that EF Core does. Right now, Enterprise users are in an effective limbo with no version or flavor of EF supporting all Enterprise needs.

The question then is why is the EF Core team so small in the first place? Microsoft should be throwing it's full weight behind you guys so it can have a truly world class ORM solution of some sort or another. Do we need to start a letter writing campaign? Maybe one of the bravest of you guys can get us Satya's cell, so we can ring that off the hook.

@ajcvickers

This comment has been minimized.

Copy link
Member

commented Mar 11, 2019

@chrisdpratt @antoinebj First, EF Core has made a lot of progress and supports many things that classic EF does not support. (However, connection pooling is supported by both.)

With regard to the size of the team, at some level there is a mapping between investment and strategic importance to Microsoft. Right now, this is the level of investment that is deemed to be appropriate. The number of votes, etc. for this issue has been explicitly raised with the people who make those calls, but as of yet there is no change to the investment. I'm not going to say that that decision is wrong because deciding where and how to strategically place investment is very difficult, and the people making these calls have much more information available than I do.

As a team, what we can commit to is:

  • Continuing to make the feedback here and elsewhere on EF Core known to the decision makers.
  • Continuing to do what we can with the resources we have and the feedback we get to make EF Core as good as we can.
@ds1709

This comment has been minimized.

Copy link

commented Mar 15, 2019

Maybe you should imlement some basic features first, such as TPT, many-to-many relations, entity splitting? It's funny to hear what EF Core "supports many things that classic EF doesnt", but also it DOES NOT supports many BASIC things that classic EF DOES, which must be implementet primarily in any ORM, whether it's EF6, EF Core, XAF or another. It's like a car with perfect interior, but without wheels. Yes, it's beautiful, but you can't ride it. Like this, EF Core, maybe it's realy supports many things that classic EF does not, but I can't use it without basic features implemented.

@papakojo

This comment has been minimized.

Copy link

commented Mar 15, 2019

wow, we were trying to design a big project and this issue stopped us dead in our tracks.
Just a question: can you provide examples/tutorials on how to implement TPH/TPC instead of TPT that involves about 10 types/classes?
I figured you guys may know something some of us haven't thought about if TPT is not a priority.
No sarcasm, just curious.

@tjad

This comment has been minimized.

Copy link

commented Mar 16, 2019

@ajcvickers My point is that if there is "not enough funding" or "not enough investor focus", then your team should have a dedicated strategy to get the community involved in supplying a PR - as in trying to coordinate this to happen at the very least. At the moment this is not happening, and I have tried to stimulate this route.
(And your investors should really make more of a priority in listening to the community - noted that you've raised this with them).

@papakojo take a look at the workaround I've posted, it may help, though you will still need to build your own ORM methods/integration for your TPT. ( #2266 (comment) )

@milosloub

This comment has been minimized.

Copy link

commented Mar 16, 2019

@tjad @ajcvickers Exactly! I think there is a lot of capable developers who can help with PRs to get ready some building blocks for the most important missing features like this.
So what about focus on guidance what is needed?

But I don't understand to steps of the release process
https://docs.microsoft.com/cs-cz/ef/core/what-is-new/roadmap#release-planning-process
It's obvious that the first point is mostly ignored. So if those lines are made for investors decisions, then all of them made very bad investment.

@emes001

This comment has been minimized.

Copy link

commented May 6, 2019

I'm not sure why I never bothered to look in EF Core supported TPT or not... I figured it was such a basic need, that it would just be available. You should've seen the look of shock/sadness/dismay on my face when I started creating DB migrations and saw what I expected to be a TPT structure come out as TPH. 😞

@JohnCOsborne

This comment has been minimized.

Copy link

commented May 10, 2019

Another person here who needs/needed TPT. Just commenting to add a +1 to those wanting TPT. If I had the time I'd look through these comments to see if there are non EF Core/Microsoft employees arguing against TPT.

@behzad888

This comment has been minimized.

Copy link

commented May 10, 2019

+1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.