[CSHARP-863] How should BsonValues be serialized for C# null? Created: 20/Nov/13 Updated: 18/Oct/15 Resolved: 22/Apr/14 |
|
| Status: | Closed |
| Project: | C# Driver |
| Component/s: | None |
| Affects Version/s: | 1.8.3 |
| Fix Version/s: | 2.0 |
| 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 | ||
| Issue Links: |
|
||||||||||||||||||||
| Backwards Compatibility: | Minor Change | ||||||||||||||||||||
| Description |
|
The C# driver currently serializes BsonValues with a C# null value as { _csharpnull : true }. For example, given a class:
The following test:
results in:
The difference is important, because otherwise if we serialized a C# null as a BsonNull then when deserialized the value would change to something else (it would no longer be a C# null, it would now be an instance of BsonNull). The driver currently treats ALL BsonValues the same way, including properties that are declared as subclasses of BsonValue. The question has been raised as to whether we should abandon this consistency and represent C# null using BsonNull in cases where BsonNull couldn't be a valid value. For example, suppose you had a different class:
This class differs from C only in that the data type of V is now BsonDateTime instead of BsonValue. Currently, the following code:
also results in:
although it could be argued that the { _csharpnull : true } encoding is not strictly necessary since during deserialization we could figure out that a BSON null must represent a C# null since a property of type BsonDateTime is not assignment compatible with BsonNull.Value. So the question posed in this ticket is: 1. Is it better to be consistent, as we currently are, and serialize all BsonValue subclasses the same way (with respect to C# null)? |
| Comments |
| Comment by Robert Stam [ 22/Apr/14 ] | ||||||||||
|
After much discussion we have decided that while it would be possible to simplify the representation of C# nulls when BSON null is not a possible value (option 2 in the description of the ticket), and in some ways option 2 could be considered more desirable, the two representations are equally workable, and changing the representation at this point would be a breaking change because a user might have written queries against the current representation. We also feel that using properties of type BsonValue (or one of its subclasses) is not very common, so this is somewhat of an edge case. | ||||||||||
| Comment by Robert Stam [ 20/Nov/13 ] | ||||||||||
|
As an aside, if the reason you are using a class like D:
is because you want the datetime value stored in V to be optional, a probably better alternative is to use a Nullable<DateTime>, as in:
|