[CSHARP-1867] Non-nullable members cannot be compared to nullable values Created: 13/Dec/16 Updated: 03/Mar/17 Resolved: 19/Dec/16 |
|
| Status: | Closed |
| Project: | C# Driver |
| Component/s: | API |
| Affects Version/s: | 2.3 |
| Fix Version/s: | 2.4.1 |
| Type: | Bug | Priority: | Minor - P4 |
| Reporter: | Ethan [X] | Assignee: | Robert Stam |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||||||||||
| Description |
|
This is a regression from 2.3 -> 2.4. When upgrading to 2.4 it broke all these queries. When doing a query such a Find where the filter is 'd => d._id == nullableId' where nullableId is a Guid? (Nullable<Guid>) there is a unsupported filter exception that throws. Here is the exception: System.ArgumentException: Unsupported filter: (Convert( {document}{_id}) == 61d29f4c-7e8a-4eb6-b7ce-c1cbbc9cd1b2). More info:
This is a non blocking issue because we can just add .Value to the nullable guid and it works Note: this actually applies to all non-nullable members compared to nullable values, not just Guid. |
| Comments |
| Comment by Githook User [ 19/Dec/16 ] | ||
|
Author: {u'username': u'rstam', u'name': u'rstam', u'email': u'robert@robertstam.org'}Message: | ||
| Comment by Robert Stam [ 14/Dec/16 ] | ||
|
We have discussed this internally and decided that even though comparing a non-nullable member to a nullable value is questionable since there should never be nulls, this happens often enough and there is a reasonable interpretation that can be made of the query, that we will start to support this officially going forward. There are two scenarios: 1. The right hand value is not null. In this case we will interpret the query exactly the same as if the value had not been nullable. In other words, we will generate:
2. The right hand value is null. In this case we will generate:
If the documents in the database were all created by serializing the POCO with the non-nullable member, there should be NO documents matching this query. Note: if there do happen to be any documents with a null for the non-nullable field, an exception will be thrown if you attempt to deserialize such documents into the POCO, because null is not a valid value for a non-nullable member. | ||
| Comment by Robert Stam [ 14/Dec/16 ] | ||
|
I can confirm that this sort of worked in 2.3. It works if the nullableId value is not null, otherwise a NullReferenceException is thrown (which would be a bug). I can also confirm that in 2.4 an exception is thrown whether or not the nullableId value is null or not. This is actually by design. See However, while the exception correctly identifies the expression that is not supported, it doesn't say why, which is confusing. It is too easy to conclude that this is a bug rather than working this way by design. I'm going to leave this ticket open for now so we can discuss whether the decision made in |