[CSHARP-228] Support standard byte order when serializing Guids Created: 18/May/11 Updated: 02/Apr/15 Resolved: 19/May/11 |
|
| Status: | Closed |
| Project: | C# Driver |
| Component/s: | None |
| Affects Version/s: | 1.0 |
| Fix Version/s: | 1.1 |
| Type: | New Feature | Priority: | Major - P3 |
| 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 |
|
Sadly, all existing C# drivers, including this official one, have been serializing Guids with the wrong byte order all along. This is because the byte array returned by Guid.ToByteArray returns an array where the first three groups (of 4, 2 and 2 bytes respectively) are reversed, as in little endian format. This is not a problem as long as only C# drivers are reading and writing the Guids. However, all other drivers are storing UUIDs with the standard byte order, so it becomes difficult to interoperate between the C# and other drivers when using Guids. This feature request is for a mechanism to allow C# applications to indicate when they would like Guids to be serialized using the standard byte order instead of Microsoft's internal byte order. For historical reasons everything will continue to default to Microsoft's byte order (so as not to break backward compatibility with existing code and data). There will be a new enum: public enum GuidByteOrder { Microsoft, Standard }To see all the changes involved in implementing this feature start by searching for occurrences of "GuidByteOrder" and follow the code changes from there (or look at the commit). |
| Comments |
| Comment by Robert Stam [ 19/May/11 ] |
|
Decided to use better names for the enum values: public enum GuidByteOrder { LittleEndian, BigEndian }As it's not so much a matter of how Microsoft defines the byte order as it is a matter of the endianness of the system the code is running on (although it just so happens that Windows most often runs on little endian platforms). The default value is still LittleEndian. |
| Comment by Robert Stam [ 19/May/11 ] |
|
Implemented. Could cause backward compatibility problems with existing data if used carelessly. |