Replies: 2 comments
-
Also looks very similar to #1121. |
Beta Was this translation helpful? Give feedback.
0 replies
-
Yes, this appears to be an example of #98. However, once #98 is implemented this use case should be tested. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
I suspect this may be one of the cases described in #98 but since I am not sure, I prefer to give the language team a chance to decide. Regardless, this may be a useful scenario to consider supporting.
Background
While exploring alternatives to enable support for eager loading with properties defined in derived types in Entity Frameowrk Core, we came up with an API that can be used in the following way (note the lambda in the call to
ThenInclude
):In this query, Level.Items is a collection of Item and Container derives from Item. Container in turn defines a collection property Items which can contain nested Item instances.
We tested separately two new overloads of
ThenInclude
:one that allows addressing properties declared on derived types of the collection element of a collection navigation property:
one for derived types on reference navigation properties:
When we tested these two new overloads separately they worked correctly. We liked the pattern because type inferences allows customers to write a very simple lambda and skip specifying all the generic arguments of the method.
However, when we did more complete testing, we found that if both overloads are declared, resolution for the collection overload fails (see dotnet/efcore#10441 for the original issue) . This seems to be caused by a limitation in overload resolution.
Compiler error
The code produces de following compiler error:
As the error indicates, the compiler is resolving to the overload labeled "ThenInclude-reference-inheritance" which is actually not applicable in this case. If you comment out or rename that overload, then the compiler is able to resolve the correct overload (labeled "ThenInclude-collection-inheritance").
Repro code
This is a self-contained repro which includes a mock implementations of the APIs we tried on EF Core. We have already decided not to use this API pattern given the compiler has this limitation, but we wanted to give the language team a chance to decide if this is something that should be addressed. It seems like it should affect other fluent APIs with similar design to Include/ThenInclude in EF Core.
Beta Was this translation helpful? Give feedback.
All reactions