-
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
Linq select cannot project an entity containing both Json columns and ICollections #30266
Comments
Hello, I am having exactly the same issue on e project, |
@maumar Any workaround here? |
problem comes from the bad interaction between json materializer code and the collection result coordinator. Fails for any collection (List, Array etc) not only ICollection interface. @meigetsu @pella-ias workaround is to project entire entity and use include to bring back the related collection, rather than project the collection directly. Include uses slightly different path which is not affected by the bug. Something like this: var list = ctx.TestEntities
.AsNoTracking()
.Include(x => x.ChildEntities)
.ToList()
.Select(t => new TestEntity()
{
Id = t.Id,
JsonColumn = t.JsonColumn,
ChildEntities = t.ChildEntities,
}).ToList(); |
…Json columns and ICollections Problem was that when we projection collection of entities we use result coordinator and generate different pattern in shaper code. Json entity shaper code is generated inside `resultContext.Values == null` block and all the products should be referred to via resultContext.Values array access. We were not doing that for json, so in the final projection code we would refer to parameters (storing the actual json entities) that were out of scope. Fix is to use the correct result coordinator pattern, just like we do for non-json entities. Fixes #30266
…Json columns and ICollections Problem was that when we projection collection of entities we use result coordinator and generate different pattern in shaper code. Json entity shaper code is generated inside `resultContext.Values == null` block and all the products should be referred to via resultContext.Values array access. We were not doing that for json, so in the final projection code we would refer to parameters (storing the actual json entities) that were out of scope. Fix is to use the correct result coordinator pattern, just like we do for non-json entities. Fixes #30266
…Json columns and ICollections Problem was that when we projection collection of entities we use result coordinator and generate different pattern in shaper code. Json entity shaper code is generated inside `resultContext.Values == null` block and all the products should be referred to via resultContext.Values array access. We were not doing that for json, so in the final projection code we would refer to parameters (storing the actual json entities) that were out of scope. Fix is to use the correct result coordinator pattern, just like we do for non-json entities. Fixes #30266
…Json columns and ICollections Problem was that when we projection collection of entities we use result coordinator and generate different pattern in shaper code. Json entity shaper code is generated inside `resultContext.Values == null` block and all the products should be referred to via resultContext.Values array access. We were not doing that for json, so in the final projection code we would refer to parameters (storing the actual json entities) that were out of scope. Fix is to use the correct result coordinator pattern, just like we do for non-json entities. Fixes #30266
…Json columns and ICollections (#30566) Problem was that when we projection collection of entities we use result coordinator and generate different pattern in shaper code. Json entity shaper code is generated inside `resultContext.Values == null` block and all the products should be referred to via resultContext.Values array access. We were not doing that for json, so in the final projection code we would refer to parameters (storing the actual json entities) that were out of scope. Fix is to use the correct result coordinator pattern, just like we do for non-json entities. Fixes #30266
@ajcvickers second customer report on this issue - patch candidate or shall we wait for a few more? |
…as regular entity collection #30266 Problem was that when we projection collection of entities we use result coordinator and generate different pattern in shaper code. Json entity shaper code is generated inside `resultContext.Values == null` block and all the products should be referred to via resultContext.Values array access. We were not doing that for json, so in the final projection code we would refer to parameters (storing the actual json entities) that were out of scope. Fix is to use the correct result coordinator pattern, just like we do for non-json entities. #30565 When we project entity collection, the shaper uses result coordinator and generates different shaper. However we process this scenario as if "regular" code path was being executed. Basically, we would generate code for collection projection outside of `resultContext.Values == null` block (this needs to happen for regular collections due to result coordination). For JSON it's not needed, because entire object is loaded from a single row. So we can move the processing into the block and then just refer to it's product in the final projection. We also need to shuffle around the order in which we build the block. We should build expressions and json entities first, then populate resultContext and then build includes (which depend on values in the context). Before we were populating result values before we generated json entities, (which didn't matter because we were not using that info) but now is necessary. Fixes #30266 Fixes #30565
…as regular entity collection #30266 Problem was that when we projection collection of entities we use result coordinator and generate different pattern in shaper code. Json entity shaper code is generated inside `resultContext.Values == null` block and all the products should be referred to via resultContext.Values array access. We were not doing that for json, so in the final projection code we would refer to parameters (storing the actual json entities) that were out of scope. Fix is to use the correct result coordinator pattern, just like we do for non-json entities. #30565 When we project entity collection, the shaper uses result coordinator and generates different shaper. However we process this scenario as if "regular" code path was being executed. Basically, we would generate code for collection projection outside of `resultContext.Values == null` block (this needs to happen for regular collections due to result coordination). For JSON it's not needed, because entire object is loaded from a single row. So we can move the processing into the block and then just refer to it's product in the final projection. We also need to shuffle around the order in which we build the block. We should build expressions and json entities first, then populate resultContext and then build includes (which depend on values in the context). Before we were populating result values before we generated json entities, (which didn't matter because we were not using that info) but now is necessary. Fixes #30266 Fixes #30565
Removing either the Json column or the collection from the projection solves the issue.
Minimal code to reproduce the error:
Stack trace:
I've found a possibly related issue on the dotnet runtime dotnet/runtime#56262
EF Core version: 7.0.2
Database provider: Microsoft.EntityFrameworkCore.SqlServer
Target framework: net7.0 (sdk 7.0.102)
Operating system: Win 10
IDE: VSCode
The text was updated successfully, but these errors were encountered: