[CSHARP-670] ObjectId constructor should throw an ArgumentOutOfRange if any of the components are out of range. Created: 28/Jan/13 Updated: 20/Mar/14 Resolved: 29/Jan/13 |
|
| Status: | Closed |
| Project: | C# Driver |
| Component/s: | None |
| Affects Version/s: | 1.7 |
| Fix Version/s: | 1.8 |
| Type: | Improvement | Priority: | Minor - P4 |
| Reporter: | Robert Stam | Assignee: | Robert Stam |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Backwards Compatibility: | Minor Change |
| Description |
|
This makes sure that the values stored in the ObjectId field are all within the range of values that can be successfully round tripped. It also prevents weird behavior with Equals and GetHashCode. Note that the driver internally is not passing invalid values to the ObjectId constructor, but user code creating a custom ObjectId might. |
| Comments |
| Comment by auto [ 29/Jan/13 ] |
|
Author: {u'date': u'2013-01-29T17:06:33Z', u'email': u'robert@10gen.com', u'name': u'rstam'}Message: |
| Comment by Robert Stam [ 29/Jan/13 ] |
|
Regarding backward compatibility: this is not backward breaking if you were already passing only valid values to the constructor or the Pack method. This is rarely backward breaking in the event that you were passing invalid values to the constructor or the Pack method and assuming that the invalid values would be truncated by the driver to fit in 3 bytes. In the case of the ObjectId constructor the truncation wouldn't happen until you serialized the ObjectId to a binary stream. In memory it was retaining the invalid value. This means that if you deserialized the ObjectId back into memory it would not compare as Equal to the one you started with. In the case of the Pack method it was truncating immediately (but silently). |
| Comment by Robert Stam [ 29/Jan/13 ] |
|
The Pack method should check its arguments also. |