Abstract projection overfetching when using intermediary projections #5031
Replies: 4 comments 3 replies
-
This is exactly why we are so opposed to the key solution. I will talk to Shay from the EF team about this. HotChocolate.Data will get a major update for 13 and we have these issues on our list to solve. |
Beta Was this translation helpful? Give feedback.
-
I know you guys are busy with other stuff, but just wanted to get an update on this issue. And also I'm curious @kresimirlesic what did you end up doing as a workaround eventually? |
Beta Was this translation helpful? Give feedback.
-
@aradalvand I have decided to split my type into multiple types (e.g. UserView + UserListView) where the performance hit by the joins is huge. Elsewhere, where the performance hit by the joins is small I have decided to live with it for now, unless the performance gets downgraded severely (then I would apply the same strategy I guess). TLDR: At the moment I am splitting my types into multiple types depending on the use case - which is obviously something that I would like to avoid :) As soon as this gets resolved I am planning on combining all of that back to the root type. |
Beta Was this translation helpful? Give feedback.
-
Any updates? |
Beta Was this translation helpful? Give feedback.
-
Is there an existing issue for this?
Describe the bug
#3650 implements what was called "abstraction projections", which as far as I'm concerned, enables your GraphQL schema to follow your EF Core model if you're taking advantage of inheritance in EF Core.
So, given an app set up like the following:
Program.cs
:Now, if a query like the following is executed against this GraphQL server:
The projection middleware now understands the inheritance side of things and thus generates the right projection expression, which is reflected in the resulting SQL that EF Core ultimately generates:
However, now imagine you have some sort of an "intermediary projection", here's the same setup above, with some additional DTO classes:
Now, if you execute the same GraphQL query mentioned above against this GraphQL server, the resulting SQL will be very different:
Notice how
Title
is being retrieved even though it was not requested in the GraphQL query. Actually, right now, ALL the columns are fetched from the data and the projection, therefore, is more or less useless.Now, I think it's worth mentioning that this is fundamentally related to #2373, as both problems actually share the same underlying issue. That being the fact that EF doesn't really recognize that it should treat instances of
LessonDto
andLessonDto
as equivalent when used in a projection expression on their own.To get a better understanding of this, take this as an example:
The generated SQL will be:
As expected.
But if you do:
Now we get quite a different looking SQL:
Clearly, EF Core is fetching everything once again, and the fundamental reason for this is that EF Core doesn't understand that
l
in a.Select(l => ...)
wherel
is of typeLessonDto
should be considered equivalent tol
in.Select(l => ...)
wherel
isLesson
, when the parameter is used on its own as an operand in an operation like this, or the case of #2373, in a null-checking operation, which was the root of the overfetching problem there as well.I'd like us to perhaps discuss the various possible solutions to problems of this sort. If HC itself can't do much about this, maybe we can prepare a proposal for a feature for EF Core that would solve all the problems of this nature, problems that arise when using intermediary projections.
In other words, maybe solutions like #4985 are, in a sense, treating the symptoms, rather than the actual root cause of the problem.
Let me know your thoughts.
Steps to reproduce
Described above.
Relevant log output
No response
Additional Context?
No response
Product
Hot Chocolate
Version
12.8.0
Beta Was this translation helpful? Give feedback.
All reactions