Query : error during compilation for queries with navigation properties and First/Single/client method operators inside a subquery #7722
Assignees
Labels
Comments
|
This happens because our current binding logic doesn't know how to bind to the the inner subquery properly |
maumar
added a commit
that referenced
this issue
Mar 3, 2017
…ulting in unnecessary data pulling Problem was that for GroupJoin we would always force materialization on participating query sources. We were doing this because we are not always able to correctly divide outer elements of the GroupJoin into correct groups. However, if the GroupJoin clause is wrapped around SelectMany clause the groups don't matter because they are getting flattened by SelectMany anyway. Fix is to recognize those scenarios and only force materialization when the correct grouping actually matters. We can avoid materialization if the GroupJoin is followed by SelectMany clause (that references the grouping) and that the grouping itself is not present anywhere else in the query. This addresses optional navigations, which is the 80% case. Manually created GroupJoins that are not modeling LeftOuterJoins still require additional materialization, but this can be addressed later as the priority is not nearly as high. This change also addresses #7722 - Query : error during compilation for queries with navigation properties and First/Single/client method operators inside a subquery. Problem here was that for some queries we don't know how to properly bind to a value buffer (when the result of binding is subquery, and not qsre). Fix/mitigation is to recognize those scenarios and force materialization on the subqueries. This can be properly addressed in later commit (i.e. by improving the binding logic) Also fixed several minor issues that were encountered once no longer do extensive materialization.
maumar
added a commit
that referenced
this issue
Mar 3, 2017
…ulting in unnecessary data pulling Problem was that for GroupJoin we would always force materialization on participating query sources. We were doing this because we are not always able to correctly divide outer elements of the GroupJoin into correct groups. However, if the GroupJoin clause is wrapped around SelectMany clause the groups don't matter because they are getting flattened by SelectMany anyway. Fix is to recognize those scenarios and only force materialization when the correct grouping actually matters. We can avoid materialization if the GroupJoin is followed by SelectMany clause (that references the grouping) and that the grouping itself is not present anywhere else in the query. This addresses optional navigations, which is the 80% case. Manually created GroupJoins that are not modeling LeftOuterJoins still require additional materialization, but this can be addressed later as the priority is not nearly as high. This change also addresses #7722 - Query : error during compilation for queries with navigation properties and First/Single/client method operators inside a subquery. Problem here was that for some queries we don't know how to properly bind to a value buffer (when the result of binding is subquery, and not qsre). Fix/mitigation is to recognize those scenarios and force materialization on the subqueries. This can be properly addressed in later commit (i.e. by improving the binding logic) Also fixed several minor issues that were encountered once no longer do extensive materialization.
maumar
added a commit
that referenced
this issue
Mar 3, 2017
…ulting in unnecessary data pulling Problem was that for GroupJoin we would always force materialization on participating query sources. We were doing this because we are not always able to correctly divide outer elements of the GroupJoin into correct groups. However, if the GroupJoin clause is wrapped around SelectMany clause the groups don't matter because they are getting flattened by SelectMany anyway. Fix is to recognize those scenarios and only force materialization when the correct grouping actually matters. We can avoid materialization if the GroupJoin is followed by SelectMany clause (that references the grouping) and that the grouping itself is not present anywhere else in the query. This addresses optional navigations, which is the 80% case. Manually created GroupJoins that are not modeling LeftOuterJoins still require additional materialization, but this can be addressed later as the priority is not nearly as high. This change also addresses #7722 - Query : error during compilation for queries with navigation properties and First/Single/client method operators inside a subquery. Problem here was that for some queries we don't know how to properly bind to a value buffer (when the result of binding is subquery, and not qsre). Fix/mitigation is to recognize those scenarios and force materialization on the subqueries. This can be properly addressed in later commit (i.e. by improving the binding logic) Also fixed several minor issues that were encountered once no longer do extensive materialization.
maumar
added a commit
that referenced
this issue
Mar 3, 2017
…ulting in unnecessary data pulling Problem was that for GroupJoin we would always force materialization on participating query sources. We were doing this because we are not always able to correctly divide outer elements of the GroupJoin into correct groups. However, if the GroupJoin clause is wrapped around SelectMany clause the groups don't matter because they are getting flattened by SelectMany anyway. Fix is to recognize those scenarios and only force materialization when the correct grouping actually matters. We can avoid materialization if the GroupJoin is followed by SelectMany clause (that references the grouping) and that the grouping itself is not present anywhere else in the query. This addresses optional navigations, which is the 80% case. Manually created GroupJoins that are not modeling LeftOuterJoins still require additional materialization, but this can be addressed later as the priority is not nearly as high. This change also addresses #7722 - Query : error during compilation for queries with navigation properties and First/Single/client method operators inside a subquery. Problem here was that for some queries we don't know how to properly bind to a value buffer (when the result of binding is subquery, and not qsre). Fix/mitigation is to recognize those scenarios and force materialization on the subqueries. This can be properly addressed in later commit (i.e. by improving the binding logic) Also fixed several minor issues that were encountered once no longer do extensive materialization.
maumar
added a commit
that referenced
this issue
Mar 3, 2017
…ulting in unnecessary data pulling Problem was that for GroupJoin we would always force materialization on participating query sources. We were doing this because we are not always able to correctly divide outer elements of the GroupJoin into correct groups. However, if the GroupJoin clause is wrapped around SelectMany clause the groups don't matter because they are getting flattened by SelectMany anyway. Fix is to recognize those scenarios and only force materialization when the correct grouping actually matters. We can avoid materialization if the GroupJoin is followed by SelectMany clause (that references the grouping) and that the grouping itself is not present anywhere else in the query. This addresses optional navigations, which is the 80% case. Manually created GroupJoins that are not modeling LeftOuterJoins still require additional materialization, but this can be addressed later as the priority is not nearly as high. This change also addresses #7722 - Query : error during compilation for queries with navigation properties and First/Single/client method operators inside a subquery. Problem here was that for some queries we don't know how to properly bind to a value buffer (when the result of binding is subquery, and not qsre). Fix/mitigation is to recognize those scenarios and force materialization on the subqueries. This can be properly addressed in later commit (i.e. by improving the binding logic) Also fixed several minor issues that were encountered once no longer do extensive materialization.
maumar
added a commit
that referenced
this issue
Mar 3, 2017
…ulting in unnecessary data pulling Problem was that for GroupJoin we would always force materialization on participating query sources. We were doing this because we are not always able to correctly divide outer elements of the GroupJoin into correct groups. However, if the GroupJoin clause is wrapped around SelectMany clause the groups don't matter because they are getting flattened by SelectMany anyway. Fix is to recognize those scenarios and only force materialization when the correct grouping actually matters. We can avoid materialization if the GroupJoin is followed by SelectMany clause (that references the grouping) and that the grouping itself is not present anywhere else in the query. This addresses optional navigations, which is the 80% case. Manually created GroupJoins that are not modeling LeftOuterJoins still require additional materialization, but this can be addressed later as the priority is not nearly as high. This change also addresses #7722 - Query : error during compilation for queries with navigation properties and First/Single/client method operators inside a subquery. Problem here was that for some queries we don't know how to properly bind to a value buffer (when the result of binding is subquery, and not qsre). Fix/mitigation is to recognize those scenarios and force materialization on the subqueries. This can be properly addressed in later commit (i.e. by improving the binding logic) Also fixed several minor issues that were encountered once no longer do extensive materialization.
maumar
added a commit
that referenced
this issue
Mar 3, 2017
…ulting in unnecessary data pulling Problem was that for GroupJoin we would always force materialization on participating query sources. We were doing this because we are not always able to correctly divide outer elements of the GroupJoin into correct groups. However, if the GroupJoin clause is wrapped around SelectMany clause the groups don't matter because they are getting flattened by SelectMany anyway. Fix is to recognize those scenarios and only force materialization when the correct grouping actually matters. We can avoid materialization if the GroupJoin is followed by SelectMany clause (that references the grouping) and that the grouping itself is not present anywhere else in the query. This addresses optional navigations, which is the 80% case. Manually created GroupJoins that are not modeling LeftOuterJoins still require additional materialization, but this can be addressed later as the priority is not nearly as high. This change also addresses #7722 - Query : error during compilation for queries with navigation properties and First/Single/client method operators inside a subquery. Problem here was that for some queries we don't know how to properly bind to a value buffer (when the result of binding is subquery, and not qsre). Fix/mitigation is to recognize those scenarios and force materialization on the subqueries. This can be properly addressed in later commit (i.e. by improving the binding logic) Also fixed several minor issues that were encountered once no longer do extensive materialization.
maumar
added a commit
that referenced
this issue
Mar 4, 2017
…ulting in unnecessary data pulling Problem was that for GroupJoin we would always force materialization on participating query sources. We were doing this because we are not always able to correctly divide outer elements of the GroupJoin into correct groups. However, if the GroupJoin clause is wrapped around SelectMany clause the groups don't matter because they are getting flattened by SelectMany anyway. Fix is to recognize those scenarios and only force materialization when the correct grouping actually matters. We can avoid materialization if the GroupJoin is followed by SelectMany clause (that references the grouping) and that the grouping itself is not present anywhere else in the query. This addresses optional navigations, which is the 80% case. Manually created GroupJoins that are not modeling LeftOuterJoins still require additional materialization, but this can be addressed later as the priority is not nearly as high. This change also addresses #7722 - Query : error during compilation for queries with navigation properties and First/Single/client method operators inside a subquery. Problem here was that for some queries we don't know how to properly bind to a value buffer (when the result of binding is subquery, and not qsre). Fix/mitigation is to recognize those scenarios and force materialization on the subqueries. This can be properly addressed in later commit (i.e. by improving the binding logic) Also fixed several minor issues that were encountered once no longer do extensive materialization.
maumar
added a commit
that referenced
this issue
Mar 10, 2017
…ulting in unnecessary data pulling Problem was that for GroupJoin we would always force materialization on participating query sources. We were doing this because we are not always able to correctly divide outer elements of the GroupJoin into correct groups. However, if the GroupJoin clause is wrapped around SelectMany clause the groups don't matter because they are getting flattened by SelectMany anyway. Fix is to recognize those scenarios and only force materialization when the correct grouping actually matters. We can avoid materialization if the GroupJoin is followed by SelectMany clause (that references the grouping) and that the grouping itself is not present anywhere else in the query. This addresses optional navigations, which is the 80% case. Manually created GroupJoins that are not modeling LeftOuterJoins still require additional materialization, but this can be addressed later as the priority is not nearly as high. This change also addresses #7722 - Query : error during compilation for queries with navigation properties and First/Single/client method operators inside a subquery. Problem here was that for some queries we don't know how to properly bind to a value buffer (when the result of binding is subquery, and not qsre). Fix/mitigation is to recognize those scenarios and force materialization on the subqueries. This can be properly addressed in later commit (i.e. by improving the binding logic) Also fixed several minor issues that were encountered once no longer do extensive materialization.
maumar
added a commit
that referenced
this issue
Mar 10, 2017
…ulting in unnecessary data pulling Problem was that for GroupJoin we would always force materialization on participating query sources. We were doing this because we are not always able to correctly divide outer elements of the GroupJoin into correct groups. However, if the GroupJoin clause is wrapped around SelectMany clause the groups don't matter because they are getting flattened by SelectMany anyway. Fix is to recognize those scenarios and only force materialization when the correct grouping actually matters. We can avoid materialization if the GroupJoin is followed by SelectMany clause (that references the grouping) and that the grouping itself is not present anywhere else in the query. This addresses optional navigations, which is the 80% case. Manually created GroupJoins that are not modeling LeftOuterJoins still require additional materialization, but this can be addressed later as the priority is not nearly as high. This change also addresses #7722 - Query : error during compilation for queries with navigation properties and First/Single/client method operators inside a subquery. Problem here was that for some queries we don't know how to properly bind to a value buffer (when the result of binding is subquery, and not qsre). Fix/mitigation is to recognize those scenarios and force materialization on the subqueries. This can be properly addressed in later commit (i.e. by improving the binding logic) Also fixed several minor issues that were encountered once no longer do extensive materialization.
maumar
added a commit
that referenced
this issue
Mar 10, 2017
…ulting in unnecessary data pulling Problem was that for GroupJoin we would always force materialization on participating query sources. We were doing this because we are not always able to correctly divide outer elements of the GroupJoin into correct groups. However, if the GroupJoin clause is wrapped around SelectMany clause the groups don't matter because they are getting flattened by SelectMany anyway. Fix is to recognize those scenarios and only force materialization when the correct grouping actually matters. We can avoid materialization if the GroupJoin is followed by SelectMany clause (that references the grouping) and that the grouping itself is not present anywhere else in the query. This addresses optional navigations, which is the 80% case. Manually created GroupJoins that are not modeling LeftOuterJoins still require additional materialization, but this can be addressed later as the priority is not nearly as high. This change also addresses #7722 - Query : error during compilation for queries with navigation properties and First/Single/client method operators inside a subquery. Problem here was that for some queries we don't know how to properly bind to a value buffer (when the result of binding is subquery, and not qsre). Fix/mitigation is to recognize those scenarios and force materialization on the subqueries. This can be properly addressed in later commit (i.e. by improving the binding logic) Also fixed several minor issues that were encountered once no longer do extensive materialization.
maumar
added a commit
that referenced
this issue
Mar 10, 2017
…ulting in unnecessary data pulling Problem was that for GroupJoin we would always force materialization on participating query sources. We were doing this because we are not always able to correctly divide outer elements of the GroupJoin into correct groups. However, if the GroupJoin clause is wrapped around SelectMany clause the groups don't matter because they are getting flattened by SelectMany anyway. Fix is to recognize those scenarios and only force materialization when the correct grouping actually matters. We can avoid materialization if the GroupJoin is followed by SelectMany clause (that references the grouping) and that the grouping itself is not present anywhere else in the query. This addresses optional navigations, which is the 80% case. Manually created GroupJoins that are not modeling LeftOuterJoins still require additional materialization, but this can be addressed later as the priority is not nearly as high. This change also addresses #7722 - Query : error during compilation for queries with navigation properties and First/Single/client method operators inside a subquery. Problem here was that for some queries we don't know how to properly bind to a value buffer (when the result of binding is subquery, and not qsre). Fix/mitigation is to recognize those scenarios and force materialization on the subqueries. This can be properly addressed in later commit (i.e. by improving the binding logic) Also fixed several minor issues that were encountered once no longer do extensive materialization.
maumar
added a commit
that referenced
this issue
Mar 10, 2017
…ulting in unnecessary data pulling Problem was that for GroupJoin we would always force materialization on participating query sources. We were doing this because we are not always able to correctly divide outer elements of the GroupJoin into correct groups. However, if the GroupJoin clause is wrapped around SelectMany clause the groups don't matter because they are getting flattened by SelectMany anyway. Fix is to recognize those scenarios and only force materialization when the correct grouping actually matters. We can avoid materialization if the GroupJoin is followed by SelectMany clause (that references the grouping) and that the grouping itself is not present anywhere else in the query. This addresses optional navigations, which is the 80% case. Manually created GroupJoins that are not modeling LeftOuterJoins still require additional materialization, but this can be addressed later as the priority is not nearly as high. Other bugs fixed alongside the main change: #7722 - Query : error during compilation for queries with navigation properties and First/Single/client method operators inside a subquery. Problem here was that for some queries we don't know how to properly bind to a value buffer (when the result of binding is subquery, and not qsre). Fix/mitigation is to recognize those scenarios and force materialization on the subqueries. This can be properly addressed in later commit (i.e. by improving the binding logic) #7497 - Error calling Count() after GroupJoin() (and removed the temporary fix to #7348 and implemented a proper one) This turned out to be a chicken-and-egg problem - we had discrepancy between query sources that we marked for materialization in case of GroupJoin + result operator, and the actual client side operation that had to be performed. We had to fix the group join materialization to allow for translation of those result operators, but without fixing this issue also we would get invalid queries in some cases. Proper fix is to force client result operator only if the GroupJoin cannot be flattened. We also now do this for all result operators, not just a subset because it was possible to generate invalid queries with operaors like Count(). This is now consistent with the behavior of RequiresMaterializationExpressionVisitor. Also fixed several minor issues that were encountered once no longer do extensive materialization.
maumar
added a commit
that referenced
this issue
Mar 11, 2017
…ulting in unnecessary data pulling Problem was that for GroupJoin we would always force materialization on participating query sources. We were doing this because we are not always able to correctly divide outer elements of the GroupJoin into correct groups. However, if the GroupJoin clause is wrapped around SelectMany clause the groups don't matter because they are getting flattened by SelectMany anyway. Fix is to recognize those scenarios and only force materialization when the correct grouping actually matters. We can avoid materialization if the GroupJoin is followed by SelectMany clause (that references the grouping) and that the grouping itself is not present anywhere else in the query. This addresses optional navigations, which is the 80% case. Manually created GroupJoins that are not modeling LeftOuterJoins still require additional materialization, but this can be addressed later as the priority is not nearly as high. Other bugs fixed alongside the main change: #7722 - Query : error during compilation for queries with navigation properties and First/Single/client method operators inside a subquery. Problem here was that for some queries we don't know how to properly bind to a value buffer (when the result of binding is subquery, and not qsre). Fix/mitigation is to recognize those scenarios and force materialization on the subqueries. This can be properly addressed in later commit (i.e. by improving the binding logic) #7497 - Error calling Count() after GroupJoin() (and removed the temporary fix to #7348 and implemented a proper one) This turned out to be a chicken-and-egg problem - we had discrepancy between query sources that we marked for materialization in case of GroupJoin + result operator, and the actual client side operation that had to be performed. We had to fix the group join materialization to allow for translation of those result operators, but without fixing this issue also we would get invalid queries in some cases. Proper fix is to force client result operator only if the GroupJoin cannot be flattened. We also now do this for all result operators, not just a subset because it was possible to generate invalid queries with operaors like Count(). This is now consistent with the behavior of RequiresMaterializationExpressionVisitor. Also fixed several minor issues that were encountered once no longer do extensive materialization.
maumar
added a commit
that referenced
this issue
Mar 14, 2017
…ulting in unnecessary data pulling Problem was that for GroupJoin we would always force materialization on participating query sources. We were doing this because we are not always able to correctly divide outer elements of the GroupJoin into correct groups. However, if the GroupJoin clause is wrapped around SelectMany clause the groups don't matter because they are getting flattened by SelectMany anyway. Fix is to recognize those scenarios and only force materialization when the correct grouping actually matters. We can avoid materialization if the GroupJoin is followed by SelectMany clause (that references the grouping) and that the grouping itself is not present anywhere else in the query. This addresses optional navigations, which is the 80% case. Manually created GroupJoins that are not modeling LeftOuterJoins still require additional materialization, but this can be addressed later as the priority is not nearly as high. Other bugs fixed alongside the main change: #7722 - Query : error during compilation for queries with navigation properties and First/Single/client method operators inside a subquery. Problem here was that for some queries we don't know how to properly bind to a value buffer (when the result of binding is subquery, and not qsre). Fix/mitigation is to recognize those scenarios and force materialization on the subqueries. This can be properly addressed in later commit (i.e. by improving the binding logic) #7497 - Error calling Count() after GroupJoin() (and removed the temporary fix to #7348 and implemented a proper one) This turned out to be a chicken-and-egg problem - we had discrepancy between query sources that we marked for materialization in case of GroupJoin + result operator, and the actual client side operation that had to be performed. We had to fix the group join materialization to allow for translation of those result operators, but without fixing this issue also we would get invalid queries in some cases. Proper fix is to force client result operator only if the GroupJoin cannot be flattened. We also now do this for all result operators, not just a subset because it was possible to generate invalid queries with operaors like Count(). This is now consistent with the behavior of RequiresMaterializationExpressionVisitor. Also fixed several minor issues that were encountered once no longer do extensive materialization.
maumar
added a commit
that referenced
this issue
Mar 15, 2017
…ulting in unnecessary data pulling Problem was that for GroupJoin we would always force materialization on participating query sources. We were doing this because we are not always able to correctly divide outer elements of the GroupJoin into correct groups. However, if the GroupJoin clause is wrapped around SelectMany clause the groups don't matter because they are getting flattened by SelectMany anyway. Fix is to recognize those scenarios and only force materialization when the correct grouping actually matters. We can avoid materialization if the GroupJoin is followed by SelectMany clause (that references the grouping) and that the grouping itself is not present anywhere else in the query. This addresses optional navigations, which is the 80% case. Manually created GroupJoins that are not modeling LeftOuterJoins still require additional materialization, but this can be addressed later as the priority is not nearly as high. Other bugs fixed alongside the main change: #7722 - Query : error during compilation for queries with navigation properties and First/Single/client method operators inside a subquery. Problem here was that for some queries we don't know how to properly bind to a value buffer (when the result of binding is subquery, and not qsre). Fix/mitigation is to recognize those scenarios and force materialization on the subqueries. This can be properly addressed in later commit (i.e. by improving the binding logic) #7497 - Error calling Count() after GroupJoin() (and removed the temporary fix to #7348 and implemented a proper one) This turned out to be a chicken-and-egg problem - we had discrepancy between query sources that we marked for materialization in case of GroupJoin + result operator, and the actual client side operation that had to be performed. We had to fix the group join materialization to allow for translation of those result operators, but without fixing this issue also we would get invalid queries in some cases. Proper fix is to force client result operator only if the GroupJoin cannot be flattened. We also now do this for all result operators, not just a subset because it was possible to generate invalid queries with operaors like Count(). This is now consistent with the behavior of RequiresMaterializationExpressionVisitor. Also fixed several minor issues that were encountered once no longer do extensive materialization.
|
issue is caused by #8526 |
ajcvickers
added
closed-fixed
ajcvickers
removed
the
closed-fixed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Example using ComplexNavigations model:
The text was updated successfully, but these errors were encountered: