Query: comparing collection navigations to null or to each other doesn't work #8364
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
|
related to #5825 |
maumar
added a commit
that referenced
this issue
May 3, 2017
…each other doesn't work Also fixes (smaller in scope) #5825 - Query: Comparing collection navigation to NULL throws Null Exception Problem was that we were not taking into account queries where collection navigation was being compared to null and/or each other. This would cause various exceptions during query compilation. Some of the common cases can be simplified, making them much easier for the query compiler (i.e. navigation rewrite) to process. When it comes to null comparison, we assume that collection navigation is only null if its parent entity is null, so we can actually just compare the parent entity to null instead e.g.: customer.Orders == null ---> customer == null ---> customer.Id == null However, it's possible that user wanted to check whether collection has any elements - we will issue a warning that the comparison to null could have unintended consequences and suggest to use .Any() instead. When collection navigations are compared to each other we can also approximate by comparing the parent entities instead (if the collections are the same INavigation). If navigations are different, we assume they are never equal. e.g.: csutomer1.Orders == customer2.Orders ---> customer1.Id == customer2.Id customer.Orders == company.ShippedOrders ---> false This is not a perfect translation, since there can be two collections with exactly the same elements coming from different navigations (e.g. two empty collections: c.CompletedOrders, c.PendingOrders) Therefore we also issue the warning in this case, saying that the result may not be what user expected.
maumar
added a commit
that referenced
this issue
May 3, 2017
…each other doesn't work Also fixes (smaller in scope) #5825 - Query: Comparing collection navigation to NULL throws Null Exception And #8366 - Query: EntityEqualityRewritingExpressionVisitor doesn't work with object.Equals method Problem was that we were not taking into account queries where collection navigation was being compared to null and/or each other. This would cause various exceptions during query compilation. Some of the common cases can be simplified, making them much easier for the query compiler (i.e. navigation rewrite) to process. When it comes to null comparison, we assume that collection navigation is only null if its parent entity is null, so we can actually just compare the parent entity to null instead e.g.: customer.Orders == null ---> customer == null ---> customer.Id == null However, it's possible that user wanted to check whether collection has any elements - we will issue a warning that the comparison to null could have unintended consequences and suggest to use .Any() instead. When collection navigations are compared to each other we can also approximate by comparing the parent entities instead (if the collections are the same INavigation). If navigations are different, we assume they are never equal. e.g.: csutomer1.Orders == customer2.Orders ---> customer1.Id == customer2.Id customer.Orders == company.ShippedOrders ---> false This is not a perfect translation, since there can be two collections with exactly the same elements coming from different navigations (e.g. two empty collections: c.CompletedOrders, c.PendingOrders) Therefore we also issue the warning in this case, saying that the result may not be what user expected. When Equals method is used (both static and instance version) we simply translate it to a == b and revisit with existing logic.
maumar
added a commit
that referenced
this issue
May 4, 2017
…each other doesn't work Also fixes (smaller in scope) #5825 - Query: Comparing collection navigation to NULL throws Null Exception And #8366 - Query: EntityEqualityRewritingExpressionVisitor doesn't work with object.Equals method Problem was that we were not taking into account queries where collection navigation was being compared to null and/or each other. This would cause various exceptions during query compilation. Some of the common cases can be simplified, making them much easier for the query compiler (i.e. navigation rewrite) to process. When it comes to null comparison, we assume that collection navigation is only null if its parent entity is null, so we can actually just compare the parent entity to null instead e.g.: customer.Orders == null ---> customer == null ---> customer.Id == null However, it's possible that user wanted to check whether collection has any elements - we will issue a warning that the comparison to null could have unintended consequences and suggest to use .Any() instead. When collection navigations are compared to each other we can also approximate by comparing the parent entities instead (if the collections are the same INavigation). If navigations are different, we assume they are never equal. e.g.: csutomer1.Orders == customer2.Orders ---> customer1.Id == customer2.Id customer.Orders == company.ShippedOrders ---> false This is not a perfect translation, since there can be two collections with exactly the same elements coming from different navigations (e.g. two empty collections: c.CompletedOrders, c.PendingOrders) Therefore we also issue the warning in this case, saying that the result may not be what user expected. When Equals method is used (both static and instance version) we simply translate it to a == b and revisit with existing logic.
maumar
added a commit
that referenced
this issue
May 4, 2017
…each other doesn't work Also fixes (smaller in scope) #5825 - Query: Comparing collection navigation to NULL throws Null Exception And #8366 - Query: EntityEqualityRewritingExpressionVisitor doesn't work with object.Equals method Problem was that we were not taking into account queries where collection navigation was being compared to null and/or each other. This would cause various exceptions during query compilation. Some of the common cases can be simplified, making them much easier for the query compiler (i.e. navigation rewrite) to process. When it comes to null comparison, we assume that collection navigation is only null if its parent entity is null, so we can actually just compare the parent entity to null instead e.g.: customer.Orders == null ---> customer == null ---> customer.Id == null However, it's possible that user wanted to check whether collection has any elements - we will issue a warning that the comparison to null could have unintended consequences and suggest to use .Any() instead. When collection navigations are compared to each other we can also approximate by comparing the parent entities instead (if the collections are the same INavigation). If navigations are different, we assume they are never equal. e.g.: csutomer1.Orders == customer2.Orders ---> customer1.Id == customer2.Id customer.Orders == company.ShippedOrders ---> false This is not a perfect translation, since there can be two collections with exactly the same elements coming from different navigations (e.g. two empty collections: c.CompletedOrders, c.PendingOrders) Therefore we also issue the warning in this case, saying that the result may not be what user expected. When Equals method is used (both static and instance version) we simply translate it to a == b and revisit with existing logic.
maumar
added a commit
that referenced
this issue
May 4, 2017
…each other doesn't work Also fixes (smaller in scope) #5825 - Query: Comparing collection navigation to NULL throws Null Exception And #8366 - Query: EntityEqualityRewritingExpressionVisitor doesn't work with object.Equals method Problem was that we were not taking into account queries where collection navigation was being compared to null and/or each other. This would cause various exceptions during query compilation. Some of the common cases can be simplified, making them much easier for the query compiler (i.e. navigation rewrite) to process. When it comes to null comparison, we assume that collection navigation is only null if its parent entity is null, so we can actually just compare the parent entity to null instead e.g.: customer.Orders == null ---> customer == null ---> customer.Id == null However, it's possible that user wanted to check whether collection has any elements - we will issue a warning that the comparison to null could have unintended consequences and suggest to use .Any() instead. When collection navigations are compared to each other we can also approximate by comparing the parent entities instead (if the collections are the same INavigation). If navigations are different, we assume they are never equal. e.g.: csutomer1.Orders == customer2.Orders ---> customer1.Id == customer2.Id customer.Orders == company.ShippedOrders ---> false This is not a perfect translation, since there can be two collections with exactly the same elements coming from different navigations (e.g. two empty collections: c.CompletedOrders, c.PendingOrders) Therefore we also issue the warning in this case, saying that the result may not be what user expected. When Equals method is used (both static and instance version) we simply translate it to a == b and revisit with existing logic.
|
fixed in c4129dc |
maumar
added
type-bug
closed-fixed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We support comparisons of qsres/reference navigations to nulls and to each other via
EntityEqualityRewritingExpressionVisitor, however collection navigations are not handled and cause exceptions later in the query compilation phase.We can recognize a few patterns to make the query models much easier for us to translate:
1.)
c.Customers == null-->c == null-->c.Id == null2.)
c1.Customers == c2.Customers-->c1 == c2-->c1.Id == c2.IdFor both cases we should issue a warning that this may not be intended behavior (e.g. c.Orders== null, could be intended to check if the customer has any orders)
The text was updated successfully, but these errors were encountered: