Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Fix to #7290 - Query compilation error or data corruption for queries…
… with GroupJoin wrapped in a subquery when the subset of columns is being projected Problem was that we were incorrectly reasoning about which query sources need to be materialized in the GroupJoin scenario. Previously, when we encountered GroupJoin, we marked its main from clause and the joined clause for materialization, but we would not do that recursively. This causes problems if the GroupJoin (e.g. optional navigation) is in a subquery - we would not mark it for materialization. This would lead to compilation errors in some cases, and in others (when there was a client-evaluation component) to data corruption. Fix is to use a QueryModelVisitor to walk the entire tree which allows all necessary query sources related to GroupJoin to be marked for materialization. This incurs a performance hit for some scenarios (groupjoin/optional navigation inside a subquery) because now we bring more columns from the database. Second part of the fix is that in LiftSubquery, when we update query sources, we would sometimes try to rewrite EntityShapers into ValueBufferShapers (if the lifted query itself is not marked for materialization). This however is not safe to do in case of GroupJoin. Fix is to only perform this conversion shapers inside ShapedQuery method.
- Loading branch information