[JAVA-3378] UUIDCodec default UuidRepresentation should be STANDARD Created: 08/Aug/19  Updated: 19/Dec/19  Resolved: 19/Dec/19

Status: Closed
Project: Java Driver
Component/s: BSON
Affects Version/s: 3.0.0
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Gabriel Couto Assignee: Jeffrey Yemin
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 10


Issue Links:
Related
related to JAVA-3518 Change default UUID representation to... Closed

 Description   

According to documentation, since version 3.0 the default UUID representation is the `STANDARD` one.

Except for `UuidCodec` default constructor uses `JAVA_LEGACY` representation, making applications still store `LUUID` by default.

It is interesting to note that `ValueCodecProvider`, which is the default codec provider uses the default constructor for `UuidCodec`, making sure that `JAVA_LEGACY`/`LUUID` type is used by default.

I think the default constructor can be changed to `STANDARD` representation, as stated in documentation, and even in code:

// changed the default subtype to STANDARD since 3.0
if (encoderUuidRepresentation == UuidRepresentation.STANDARD) {
 writer.writeBinaryData(new BsonBinary(BsonBinarySubType.UUID_STANDARD, binaryData));
} else {
 writer.writeBinaryData(new BsonBinary(BsonBinarySubType.UUID_LEGACY, binaryData));
}

Environment variables could be used to restore legacy behaviour withour resorting to mess with code.



 Comments   
Comment by Jeffrey Yemin [ 19/Dec/19 ]

Now that JAVA-3518 is done, I'm closing this request. I recognize that the solution we came up with in the linked specification may not be to your liking, but on balance we believe it to be the best compromise we had available to us given the state of UUID decoding/encoding in the various MongoDB drivers.

Comment by Jeffrey Yemin [ 19/Dec/19 ]

See https://github.com/mongodb/specifications/blob/master/source/uuid.rst for the cross-driver specification for handling UUID encoding and decoding.

Also linked to JAVA-3518, under which we change the default UUID representation to UNSPECIFIED. This will be included in the upcoming 4.0 release of the driver.

Comment by Gabriel Couto [ 23/Aug/19 ]

Thanks for the reply Jeffrey,

I know that keeping legacy applications working is the main concern of any change.
But my point is that its kind of weird that there are references saying the default was going to change, and, at the same time, currently I have to basically make a custom ValueCodecProvider and CodecRegistry so that the driver can use the correct implementation of UUID, instead of LUUID. That is a terrible and non-portable solution.

If one application from our stack decides to use the the correct implementation of UUID, we will have to ship a library and create custom configuration for each of them.

That could be easily solved with some environment/jvm variable. I wonder if the drivers for other languages treat the correct UUID as second-class citizen too.

We have given up on using UUID because we thought configuring it on our whole ecosystem seems to be to much of trouble.

Comment by Jeffrey Yemin [ 19/Aug/19 ]

Hi gmcouto@gmail.com,

I understand your desire for Standard to be the default. It's ours as well, but we have to be careful. If we just change the default, we risk data corruption for existing applications that already have legacy UUID data in their MongoDB collections.

We're working on a plan for 4.0 to change the default to standard, but in a way that protects existing applications.

Comment by Gabriel Couto [ 08/Aug/19 ]

I thought JIRA used markdown, sorry for the misformating. My first time on JIRA.

Generated at Thu Feb 08 08:59:28 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.