[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:
Duplicate
is duplicated by CSHARP-1865 Unsupported filter exception after up... Closed
is duplicated by CSHARP-1453 Expressions used to resolve field nam... Closed
Related
related to CSHARP-1083 Null reference when serialize logical... Closed
related to CSHARP-1865 Unsupported filter exception after up... Closed
related to CSHARP-1273 Find() fails with "Object reference n... Closed
is related to CSHARP-506 Throw better exception when comparing... Closed

 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:

  • we do a BsonRepresentation(BsonType.String) for all of our guids
  • changing the query to d => d._id == nullableId.Value fixes the issue
  • this is a regression

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: CSHARP-1867: Non-nullable members cannot be compared to nullable values.
Branch: master
https://github.com/mongodb/mongo-csharp-driver/commit/e7f872afc0b620d6540af70d8a0f6d7b25ee82bd

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:

{ nonNullableFieldName : nullableValue.Value }

2. The right hand value is null. In this case we will generate:

{ nonNullableFieldName : null }

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 CSHARP-506.

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 CSHARP-506 was right or not.

Generated at Wed Feb 07 21:40:53 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.