Skip to content
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

Navs: nav expansion on GJ QSRE in projection doesn't introduce parameter #8186

Closed
anpete opened this issue Apr 16, 2017 · 2 comments
Closed
Assignees
Labels
closed-fixed The issue has been fixed and is/will be included in the release indicated by the issue milestone. type-bug
Milestone

Comments

@anpete
Copy link
Contributor

anpete commented Apr 16, 2017

from c in context.Set<Customer>()
join o in context.Set<Order>()
on c.CustomerID equals o.CustomerID into g
where c.CustomerID == "ALFKI"
select new { c, G = g.Select(o => _Include(o, o.OrderDetails)).ToList() })

produces:

SELECT [c].[CustomerID], [c].[Address], [c].[City], [c].[CompanyName], [c].[ContactName], [c].[ContactTitle], [c].[Country], [c].[Fax], [c].[Phone], [c].[PostalCode], [c].[Region], [o].[OrderID], [o].[CustomerID], [o].[EmployeeID], [o].[OrderDate]
FROM [Customers] AS [c]
LEFT JOIN [Orders] AS [o] ON [c].[CustomerID] = [o].[CustomerID]
WHERE [c].[CustomerID] = N'ALFKI'
ORDER BY [c].[CustomerID]
  
SELECT [o0].[OrderID], [o0].[ProductID], [o0].[Discount], [o0].[Quantity], [o0].[UnitPrice]
FROM [Order Details] AS [o0]

SELECT [o0].[OrderID], [o0].[ProductID], [o0].[Discount], [o0].[Quantity], [o0].[UnitPrice]
FROM [Order Details] AS [o0]
from c in context.Set<Customer>()
join o in context.Set<Order>()
on c.CustomerID equals o.CustomerID into g
where c.CustomerID == "ALFKI"
select new { c, G = g.Select(o => _Include(o, o.Customer)).ToList() }

produces:

SELECT [c].[CustomerID], [c].[Address], [c].[City], [c].[CompanyName], [c].[ContactName], [c].[ContactTitle], [c].[Country], [c].[Fax], [c].[Phone], [c].[PostalCode], [c].[Region], [o].[OrderID], [o].[CustomerID],
[o].[EmployeeID], [o].[OrderDate]
FROM [Customers] AS [c]
LEFT JOIN [Orders] AS [o] ON [c].[CustomerID] = [o].[CustomerID]
WHERE [c].[CustomerID] = N'ALFKI'
ORDER BY [c].[CustomerID]

SELECT [o.Customer].[CustomerID], [o.Customer].[Address], [o.Customer].[City], [o.Customer].[CompanyName], [o.Customer].[ContactName], [o.Customer].[ContactTitle], [o.Customer].[Country], [o.Customer].[Fax], [o.Customer].[Phone], [o.Customer].[PostalCode], [o.Customer].[Region]
FROM [Customers] AS [o.Customer]
@anpete anpete changed the title Navs: Collection expansion on GJ QSRE in projection doesn't introduce parameter Navs: nav expansion on GJ QSRE in projection doesn't introduce parameter Apr 16, 2017
@ajcvickers ajcvickers modified the milestones: 2.0.0, 2.0.0-preview1 Apr 17, 2017
maumar added a commit that referenced this issue Jun 7, 2017
…ntroduce parameter

Problem was that when trying to find query to bind with via outer parameter we were too strict and would not find the appropriate query. We used to share the logic for regular binding and outer parameter binding, however the latter can be more loose and therefore bind to bigger range of queries (e.g. client-side groupjoin).

This also enables additional include scenarios when GJ qsre is projected - fixed a small bug in this area that was exposed by the main fix.
maumar added a commit that referenced this issue Jun 7, 2017
…ntroduce parameter

Problem was that when trying to find query to bind with via outer parameter we were too strict and would not find the appropriate query. We used to share the logic for regular binding and outer parameter binding, however the latter can be more loose and therefore bind to bigger range of queries (e.g. client-side groupjoin).

This also enables additional include scenarios when GJ qsre is projected - fixed a small bug in this area that was exposed by the main fix.
maumar added a commit that referenced this issue Jun 7, 2017
…ntroduce parameter

Problem was that when trying to find query to bind with via outer parameter we were too strict and would not find the appropriate query. We used to share the logic for regular binding and outer parameter binding, however the latter can be more loose and therefore bind to bigger range of queries (e.g. client-side groupjoin).

This also enables additional include scenarios when GJ qsre is projected - fixed a small bug in this area that was exposed by the main fix.
maumar added a commit that referenced this issue Jun 7, 2017
…ntroduce parameter

Problem was that when trying to find query to bind with via outer parameter we were too strict and would not find the appropriate query. We used to share the logic for regular binding and outer parameter binding, however the latter can be more loose and therefore bind to bigger range of queries (e.g. client-side groupjoin).

This also enables additional include scenarios when GJ qsre is projected - fixed a small bug in this area that was exposed by the main fix.
maumar added a commit that referenced this issue Jun 7, 2017
…ntroduce parameter

Problem was that when trying to find query to bind with via outer parameter we were too strict and would not find the appropriate query. We used to share the logic for regular binding and outer parameter binding, however the latter can be more loose and therefore bind to bigger range of queries (e.g. client-side groupjoin).

This also enables additional include scenarios when GJ qsre is projected - fixed a small bug in this area that was exposed by the main fix.
@smitpatel
Copy link
Contributor

Quick summary for @anpete of the discussion.

Binding to outer parameter is relational concept at present. That means we bind to outer parameter only if QSRE on which outer parameter is generated is fully translated.
E.g. q.property will be converted to outer parameter only if q is result of SelectExpression or part of it. (but outer parameter because we couldn't lift current QM to outer QM.) It is that way because the logic is we find SE for querysource and then bind the property by using projection.

For this case, the outer QM is not exactly SelectExpression since there is client side processing for group join. So when we try to find the SelectExpression for querysource, there is none and we cannot convert to outer parameter. Client eval follows.

What should happen is, if we cannot find SelectExpression then we should fall to Core Level outer parameter introduction which basically binds with result of client _GroupJoin. At present we already have way to translate this (which is called when we do client translation of predicate but it should be applied to left/right parts of predicate separately). The translation generated for client predicate's left side can be used for outer parameter. Introduction of this will ensure that whenever we are producing N+1 queries we always introduce outer parameter because we can generate outer parameter with client side methods too.

maumar added a commit that referenced this issue Jun 8, 2017
…ntroduce parameter

Problem was that when trying to find query to bind with via outer parameter we were too strict and would not find the appropriate query. However it is also safe to bind to grouping qsre, even though it is wrapped by client GroupJoin.

This also enables additional include scenarios when GJ qsre is projected - fixed a small bug in this area that was exposed by the main fix.

Gf
maumar added a commit that referenced this issue Jun 8, 2017
…ntroduce parameter

Problem was that when trying to find query to bind with via outer parameter we were too strict and would not find the appropriate query. However it is also safe to bind to grouping qsre, even though it is wrapped by client GroupJoin.

This also enables additional include scenarios when GJ qsre is projected - fixed a small bug in this area that was exposed by the main fix.
@maumar
Copy link
Contributor

maumar commented Jun 8, 2017

fixed in 32a196a

@maumar maumar closed this as completed Jun 8, 2017
@maumar maumar added the closed-fixed The issue has been fixed and is/will be included in the release indicated by the issue milestone. label Jun 8, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
closed-fixed The issue has been fixed and is/will be included in the release indicated by the issue milestone. type-bug
Projects
None yet
Development

No branches or pull requests

4 participants