[CSHARP-1884] In should still work when TField is not exactly right (like it used to) Created: 06/Jan/17 Updated: 02/Jun/22 Resolved: 27/Jan/17 |
|
| Status: | Closed |
| Project: | C# Driver |
| Component/s: | API |
| Affects Version/s: | 2.4.1 |
| Fix Version/s: | 2.4.2 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Gian Maria Ricci | Assignee: | Robert Stam |
| Resolution: | Done | Votes: | 1 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Description |
|
Take this little class
Notice that the TAGS property is an array of string. And now this query that runs perfectly fine with 2.4.0 version or earlier
I know that this query is not really correct, because it should use the AnyIn operator, but it runs fine with every version of 2.x driver up to 2.4.0, and also if you know Mongo javascript api you are perfectly fine issuing an $in query for a property that is an array of string. Now if you upgrade the driver to 2.4.1 the above query have an error.
I know that the query should be really changed to AnyIn, but this is a breaking compatibility with version 2.4.0 and it requires at least a change in minor driver number. |
| Comments |
| Comment by Githook User [ 27/Jan/17 ] | ||||||
|
Author: {u'username': u'rstam', u'name': u'rstam', u'email': u'robert@robertstam.org'}Message: | ||||||
| Comment by Robert Stam [ 14/Jan/17 ] | ||||||
| Comment by Robert Stam [ 13/Jan/17 ] | ||||||
|
This is due to the same underlying issue of | ||||||
| Comment by Robert Stam [ 06/Jan/17 ] | ||||||
|
The problem is with this line:
The compiler is inferring that the field is of type string, so what the compiler sees is:
but the actual field is of type string[]. If we tell the compiler the correct type of the field then we get a compile time error:
I believe this was only working "by accident" in 2.4.0. The In method is only intended to be used with scalar fields (not array fields). | ||||||
| Comment by Robert Stam [ 06/Jan/17 ] | ||||||
|
I can reproduce this without calling Find by calling Render:
In version 2.4.0 of the driver this renders as:
And in version 2.4.1 it throws the exception that you reported. |