Change default Mongo UUID representation to STANDARD/v4 (Criteria)

[mathansen]

No description provided.

[mathansen]

I noticed that UUID values are serialized using the legacy v3 format instead of the current v4 when using the Criteria module. The default has changed to v4 on the Mongo side for quite a while. I made the representation configurable, for folks who need/want to keep using the legacy version, but it shouldn't be the default IMHO.

[asereda-gs]

Is this change backwards compatible? I does change the default UUID representation from JAVA_LEGACY to STANDARD.

Looking at UuidCodec decoding can be done with either formats so technically it may work. I'm just worried that UUIDs will be stored if multiple formats (unless all of them are rewritten).

[asereda-gs]

I wonder if we can expose directly ctor BsonModule(CodecRegistry) (link). It can be composed with CodecRegistries.withUuidRepresentation

[asereda-gs]

Perhaps you can also try the following:

CodecRegistry registry = JacksonCodecs.registryFromMapper(mapper); // or some other way to instantiate registry
registry = CodecRegistries.withUuidRepresentation(registry, UuidRepresentation.STANDARD);

[mathansen]

Perhaps you can also try the following:

CodecRegistry registry = JacksonCodecs.registryFromMapper(mapper); // or some other way to instantiate registry
registry = CodecRegistries.withUuidRepresentation(registry, UuidRepresentation.STANDARD);

I just tried this and it didn't have any effect.

I wonder if we can expose directly ctor BsonModule(CodecRegistry) (link). It can be composed with CodecRegistries.withUuidRepresentation

I think that would be a good idea, at least it is something that can be done immediately without breaking anything. In the long run (perhaps for the next major release) I would suggest removing the hard-coded LEGACY flag and just using whatever the current default of the Mongo driver is.

Is this change backwards compatible? I does change the default UUID representation from JAVA_LEGACY to STANDARD.

Looking at UuidCodec decoding can be done with either formats so technically it may work. I'm just worried that UUIDs will be stored if multiple formats (unless all of them are rewritten).

It is backward compatible if you are using a v4 Mongo driver. New records will be written with v4 whereas the old ones will remain on v3. The switch to v4 might cause issues for applications that share their database with other applications that might use older drivers without support for v4 encoding.

[mathansen]

I just had a look at this again and there seem to be only two relevant places where the UUIDCodec(UuidRepresentation) constructor is used during runtime (instead of the default UUIDCodec() no-argument constructor:

1. org.immutables.criteria.mongo.bson4jackson.BsonModule#defaultRegistry()
2. com.mongodb.internal.session#createNewServerSessionIdentifier()

Unfortunately, the first one takes precedence for encoding properties (and hence is causing the issue). Imho, the configuration of the codec should be left to the driver (which in turn can be configured by the user).

The Spring Boot project for example configures the driver to use JAVA_LEGACY by default (probably for compatibility reasons). See https://github.com/spring-projects/spring-boot/blob/main/spring-boot-project/spring-boot-autoconfigure/src/main/java/org/springframework/boot/autoconfigure/mongo/MongoProperties.java#L111 .

To summarize, I believe the hard-coded configuration of the legacy codec should be removed and the default no-arg constructor should be used instead.