You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
... triggers a failure in DEBUG only (also in 7.0), from TableAliasVerifyingExpressionVisitor. The SQL that would get generated (without the check) is the following:
SELECT [o].[Quantity] AS [Key], (
SELECTMAX([o3].[OrderDate])
FROM [Order Details] AS [o2]
INNER JOIN [Orders] AS [o3] ON [o2].[OrderID] = [o3].[OrderID]
WHERE [o2].[OrderID] =8AND [o].[Quantity] = [o2].[Quantity]) AS [MaxTimestamp]
FROM [Order Details] AS [o]
WHERE [o].[OrderID] =8GROUP BY [o].[Quantity]
ORDER BY (
SELECTMAX([o3].[OrderDate])
FROM [Order Details] AS [o2]
INNER JOIN [Orders] AS [o3] ON [o2].[OrderID] = [o3].[OrderID]
WHERE [o2].[OrderID] =8AND [o].[Quantity] = [o2].[Quantity])
Note that [o1] is missing, which is what triggers the error. The check is generally to detect referential integrity issues, but this seems to be a false positive.
What's happening is that the same SelectExpression instance is referenced from both the ordering and the projection; when we apply the projection after translation, we uniquify the aliases within; this mutates the TableReferenceExpression, but since that's shared, the change occurs both in the ordering and in the projection.
AFAICT this has no actual effect except for the aliases not being properly ordered in the final SQL (but it blocks proper testing on #32234). Ideally, if we get to a place where ColumnExpressions reference TableExpressionBases directly (no more TableReferenceExpression) and everything is properly immutable, this would go away on its own.
Discovered as part of the work on #32234 - we generally have problems with SelectExpression which are referenced multiple times.
The text was updated successfully, but these errors were encountered:
The following Northwind query:
... triggers a failure in DEBUG only (also in 7.0), from TableAliasVerifyingExpressionVisitor. The SQL that would get generated (without the check) is the following:
Note that [o1] is missing, which is what triggers the error. The check is generally to detect referential integrity issues, but this seems to be a false positive.
What's happening is that the same SelectExpression instance is referenced from both the ordering and the projection; when we apply the projection after translation, we uniquify the aliases within; this mutates the TableReferenceExpression, but since that's shared, the change occurs both in the ordering and in the projection.
AFAICT this has no actual effect except for the aliases not being properly ordered in the final SQL (but it blocks proper testing on #32234). Ideally, if we get to a place where ColumnExpressions reference TableExpressionBases directly (no more TableReferenceExpression) and everything is properly immutable, this would go away on its own.
Discovered as part of the work on #32234 - we generally have problems with SelectExpression which are referenced multiple times.
The text was updated successfully, but these errors were encountered: