-
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
InMemory: When adding subquery projection, take into account client projection #17620
Comments
So how exactly are we supposed to work around this? Using an anonymous object doesn't work either, and we can't create tuples in expressions? We are just now attempting to update to dotnet 3 (from 2.2), and we have a bunch of failing tests because of this.. |
any update on this? |
I'm getting this exact error, but in a different, quite specific, situation. Scenario: Fetching a Parent-ChildCollection and projecting to new Parent-ChildAggregate with a nested Parent.OwnedEntityProperty. Json representation of source Parent entity structure: Whenever I try aggregate the child list AND retrieve the nested value object, I get the I created a simple console app and proved that this is the only scenario it happens in.
In my real project the last scenario succeeds against SQL Server, I have not tried this sample against SQL. To work around this I am checking if the Db is in memory, then split the query into 2. That way my tests pass, and I still have the performance of a single read to the real Db. |
Really keen to hear if there is an ETA for this. It's a blocker for our migration to 3.1 at this point. |
For anyone coming across this because they're trying to use a @PoyaManouchehri don't know if this helps you? |
I have this exception used Select and Count together.
|
@jgbpercy I can confirm that our original issue (exception when using |
.Any() is still a problem for me in EF Core InMemory 3.1.7. When I replace .any() with .Count() > 0 my tests pass. |
This still fails in 3.1.8 in InMemoryDatabase but works fine in SQL Server/PostgreSQL. Exception
code public static IQueryable<ContainerDto> ToDtoList(this IQueryable<Container> data)
{
return data.Select(AsDto);
}
public static readonly Expression<Func<Container, ContainerDto>> AsDto =
item => new ContainerDto
{
Text = item.Text,
Cars = item.Cars
.AsQueryable()
.Select(AsCarDto)
.FirstOrDefault(),
};
public static readonly Expression<Func<Car, CarDto>> AsCarDto =
item => new CarDto
{
Name = item.Name,
}; |
I am having the same problem as reply above. Works in SQL Server but not InMemoryDatabase. Is there a known workaround? Thanks! |
Implement left join as client method to reduce complexity To resolve the indexing issue stemming from #23934 Now all the projections are applied immediately to reshape the value buffer so that all our future bindings are always read value expressions which refers to a proper index. In order to do this, we apply select for entity type with hierarchy to avoid entity check conditional expression. For adding projection (through ReplaceProjectionMapping), - For client projection, we apply a select and re-generate client projection as read values - For projection mapping, we iterate the mappings, we apply a select and re-generate the mapping as read values - If projection mapping is empty then we add a dummy 1 so that it becomes non-range-variable When applying projection, we generate a selector lambda to form a value buffer and replace all the expressions to read from new value buffer. Overall this solves the issue of having complex expressions to map or pull. This also removed PushDownIntoSubquery method. In order to avoid the issue of indexes changing when generating join due to iterating projection mappings, we now also have projectionMappingExpressions which remembers the all expressions inside projectionMapping (which are all read value as we generated before). So now we don't need to iterate the mapping and we use the existing expressions directly. This keeps existing indexes. Resolves #13561 Resolves #17539 Resolves #18194 Resolves #18435 Resolves #19344 Resolves #19469 Resolves #19667 Resolves #19742 Resolves #19967 Resolves #20359 Resolves #21677 Resolves #23360 Resolves #17537 Resolves #18394 Resolves #23934 Resolves #17620 Resolves #18912
See #16963 (comment)
The text was updated successfully, but these errors were encountered: