-
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
FirstOrDefault after custom projection == null cannot be translated #18476
Comments
@groege Please post a small, runnable project/solution or complete code listing that demonstrates the issue. This will ensure that we can reproduce what you are seeing. |
So I apologize - queryB actually works - I did have an error in my code (Which I found by doing the repro). But queryA.Where(x => x.ModelPropA == null).ToList() is not working, it sais it cannot be translated. Thanks for your time!! |
Simpler query var query = db.Blogs.Where(e => db.Blogs.Select(b => new { b.Id }).FirstOrDefault() == null).ToList(); |
@smitpatel thanks! |
@groege - Your normal where clause has custom projection preceding it. The simpler query is for repro and not a work-around. |
This is anonymous type comparison. |
Notes:
|
This is only true if the projection type is non-nullable hence null will produced from empty sequence only. If the result type is nullable then a non-empty sequence can also give null. |
Re-activating as we didn't really fix this issue. |
…tion Resolves #26744 A better fix for #18476 Initial fix for #18476 assumed that whenever we have single result operation compared to null, it will only be true if the result of single result is default when sequence is empty. This was correct for the query in the issue tracker which had anonymous type projection. Anonymous type is never null as long as there is data, it can be only null value when default is invoked i.e. empty sequence. Hence we added optimization for that but it didn't restrict to just anonymous type. For entity type projection when entity is not nullable, the same logic holds true. This helped us translate queries which wouldn't work with entity equality due to composite key from a subquery. But optimization was incorrect for the result which can be null (nullable scalar or nullable entity) as an non-empty sequence can have first result to be null which can match. The improved fix avoids doing the unrestricted optimization during preprocessing phase. Instead we moved the logic to translation phase where we can evaluate the shape of the projection coming out subquery. Now we only apply optimization for non-nullable entity and anonymous type. Scalar comparison will work by comparing to null and nullable entity will work if entity equality covers it. It will start throwing error if composite key though earlier version possibly generated wrong results for it.
@ajcvickers - While this is not really patch issue, it is getting fixed in 6.0 branch as fixing bug for #26744 Not sure how to set milestone on this one now. |
…tion (#27284) Resolves #26744 A better fix for #18476 Initial fix for #18476 assumed that whenever we have single result operation compared to null, it will only be true if the result of single result is default when sequence is empty. This was correct for the query in the issue tracker which had anonymous type projection. Anonymous type is never null as long as there is data, it can be only null value when default is invoked i.e. empty sequence. Hence we added optimization for that but it didn't restrict to just anonymous type. For entity type projection when entity is not nullable, the same logic holds true. This helped us translate queries which wouldn't work with entity equality due to composite key from a subquery. But optimization was incorrect for the result which can be null (nullable scalar or nullable entity) as an non-empty sequence can have first result to be null which can match. The improved fix avoids doing the unrestricted optimization during preprocessing phase. Instead we moved the logic to translation phase where we can evaluate the shape of the projection coming out subquery. Now we only apply optimization for non-nullable entity and anonymous type. Scalar comparison will work by comparing to null and nullable entity will work if entity equality covers it. It will start throwing error if composite key though earlier version possibly generated wrong results for it.
Steps to reproduce
StackTrace
Further technical details
EF Core version:
Database provider: Npgsql.EntityFrameworkCore.PostgreSQL 3.0.0
Target framework: NET Core 3.0
Operating system: WIN10
IDE: Visual Studio 2019 16.4.0 Preview 1.0
The text was updated successfully, but these errors were encountered: