-
Notifications
You must be signed in to change notification settings - Fork 3.2k
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
Complete Discriminator mapping #18106
Comments
This is by design. We add predicate to make sure that we only select records which correspond to one of the types we know. Your table may have additional values in discriminator column which we don't know about and it can throw runtime exception. It is similar to having non-mapped columns and EF Core selecting only columns we know explicitly. |
We could allow to mark the discriminator as 'complete' and make this perf improvement. |
Related to #2594 |
@ajcvickers
You're right, I did mean "involves any/every type in the hierarchy". But just to be sure I got it right... Let's assume a program involving Students and Teachers Now, there can be 2 scenarios depending on the use-case In both scenarios, the enum will have to have 3 values, or EF core will not allow us to it as a discriminator. In scenario A, only 2 of those 3 enum values will actually be present in the data In scenario A, when using In scenario B, ambiguity comes in. When using
What I am looking for is better performance in Scenario A by eliminating the extra where clause. Personally, I never had experience with a use case like Scenario B, even if I did, I'd probably avoid it by using a 4th enum value for "normal" Users, and thus convert it to Scenario A. Which is why I like the idea put forward in #18106 (comment), because that would allow the developer to chose what's best for them. |
Clearing the milestone here to discuss with the team. Making this the default would fix the simple raw SQL issue for composing over TPH tables: #18232 |
Filed #20192 for default decision. |
- Add fluent API IsComplete over DiscriminatorBuilder - In query if mapping is complete - Don't generate predicate when creating Select for an entityType - Don't apply predicate when doing OfType of derived type when the discriminator is not needed Current default: Mapping is incomplete unless user uses fluent API to mark it as complete. Resolves #18106
- Add fluent API IsComplete over DiscriminatorBuilder - In query if mapping is complete - Don't generate predicate when creating Select for an entityType - Don't apply predicate when doing OfType of derived type when the discriminator is not needed Current default: Mapping is incomplete unless user uses fluent API to mark it as complete. Resolves #18106
- Add fluent API IsComplete over DiscriminatorBuilder - In query if mapping is complete - Don't generate predicate when creating Select for an entityType - Don't apply predicate when doing OfType of derived type when the discriminator is not needed Current default: Mapping is incomplete unless user uses fluent API to mark it as complete. Resolves #18106
- Add fluent API IsComplete over DiscriminatorBuilder - In query if mapping is complete - Don't generate predicate when creating Select for an entityType - Don't apply predicate when doing OfType of derived type when the discriminator is not needed Current default: Mapping is incomplete unless user uses fluent API to mark it as complete. Resolves #18106
- Add fluent API IsComplete over DiscriminatorBuilder - In query if mapping is complete - Don't generate predicate when creating Select for an entityType - Don't apply predicate when doing OfType of derived type when the discriminator is not needed Current default: Mapping is incomplete unless user uses fluent API to mark it as complete. Resolves #18106
I discovered that (at least for queries to mysql) a where clause on the discriminator is formed, even if all derived classes are selected. This slows down remarkably even if you add an index on the discriminator field when millions of rows are in the table.
There are no other derived classes than union, person and organisation, but still ef core forms this where clause:
WHERE
o
.Discriminator
IN ('Union', 'Person', 'Organisation')Just skip the where Discriminator in ('class1','class2',...) when all classes are selected.
The text was updated successfully, but these errors were encountered: