-
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
Query: incorrect sql generated for query with owned entities, left join and predicate using inner qsre #8492
Comments
Check materialization status for l1/l2. Probably l1 is not materialized (since we are picking up l1.id only & if l2 is materialized then we would copy over all projections while creating left join. |
that's one issue for sure (l2 shouldn't be materialized), but on top of that, we should at least have l1.Id in the final projection - we do not. Instead, [t1].Id is present twice (pos 0 and pos 6), and the pos 6 one is used in the final client selector |
Both t1.Id could have different structure. Basically when we are binding l1.Id, we could try to find column Id property inside table t1 and that gives us t1.Id (since internal projections are incorrect, the external one was bound incorrectly too. |
problem surfaces because RequiresMaterializationExpressionVisitor is not able to find entity type for |
If |
its just how expression printer displays stuff |
…tities, left join and predicate using inner qsre Problem was that for queries with owned types that were using GroupJoin-SelectMany-DefaultIfEmpty pattern we were not able to find the owned entity type behind the groupjoin subquery qsre. Usually (i.e. in case of navigations) we look for the entity type in the lookup on QueryCompilationContext, but if the groupjoin is created manually then this lookup is not populated with entry for the groupjoin subquery. Fix is to extract JoinClause behind the groupjoin subquery qsre and try to match it against the lookup.
…tities, left join and predicate using inner qsre Problem was that for queries with owned types that were using GroupJoin-SelectMany-DefaultIfEmpty pattern we were not able to find the owned entity type behind the groupjoin subquery qsre. Usually (i.e. in case of navigations) we look for the entity type in the lookup on QueryCompilationContext, but if the groupjoin is created manually then this lookup was not populated with entry for the groupjoin subquery. Fix is to populate the lookup with entry for groupjoin subquery qsre. We do it in nav rewrite, which also populates other entries for owned types.
…tities, left join and predicate using inner qsre Problem was that for queries with owned types that were using GroupJoin-SelectMany-DefaultIfEmpty pattern we were not able to find the owned entity type behind the groupjoin subquery qsre. Usually (i.e. in case of navigations) we look for the entity type in the lookup on QueryCompilationContext, but if the groupjoin is created manually then this lookup was not populated with entry for the groupjoin subquery. Fix is to populate the lookup with entry for groupjoin subquery qsre. We do it in nav rewrite, which also populates other entries for owned types.
fixed in 552f70a |
query:
query model after nav rewrite:
generated sql:
note that projected columns come from the joined entity (l2), instead of expected l1.
If the predicate is removed, or changed so that l1.Name is being used, everything works fine:
The text was updated successfully, but these errors were encountered: