KMongo configuration refactoring

[zigzago]

@marcdejonge @chakwok

Here are all the configuration classes at this time:

• CollectionNameFormatter
• UpdateConfiguration
• ObjectMappingConfiguration (only supported by "native" mapping for now)

And for jackson mapping:

• KMongoConfiguration

All are singleton, and there are at least three issues with that:

• you can have only one configuration by jvm
• you need to be cautious with initialization order
• hot reload can be a problem

So why has it been designed as it is?

• KMongo provides some "stateless" extensions (like String.bson, String.json, KProperty.path(), etc. ) so we need at least one "default" configuration for them

• The KMongo configuration is injected via the codecRegistry into the MongoClient, MongoDatabase and MongoCollection interfaces.(see configureRegistry or withKMongo ). The only way I see at this time to know which configuration is used by one of these three interfaces (so we can use the configuration in the extensions) is to add a "marker" in the CodecRegistry to link the CodecRegistry to the custom configuration. Looks like a hack :(

• Also this codecRegistry is loaded using ServiceLoader, in order to support the three mapping engines (jackson/pojo-native/kotlinx-serialization). So we need to find a way to link the custom configuration to the class loaded with the ServiceLoader.

What would be an implementation?

Create a public KMongoRegistry class that implements CodecRegistry. The custom KMongoConfiguration would be a property of this KMongoRegistry

Is it a breaking change ?

Not sure. You still need a "default" configuration. May be we will deprecate some methods or classes ;)

A PR is welcome :)

[marcdejonge]

I'd love to spend a bit of time on it, but that'll be a bit later. In the meantime, is there a chance that the latest changes will be released soon? I'll make my project a lot simpler ;)

[zigzago]

The 4.0.2-SNAPSHOT has already the fix (in https://oss.sonatype.org/content/repositories/snapshots repo).

If you don't want to have snapshots dependencies in your project, I'm waiting for a new java mongo driver release to release the next version of kmongo.

Next release 4.0.4 is scheduled for June 2 in the mongo java driver JIRA: https://jira.mongodb.org/projects/JAVA/versions/27421 ;)

[marcdejonge]

ok, thank! We'll probably wait for the second of June.

[rocketraman]

Registering serializers / serializer modules with kotlinx-serialization also relies on functions that are not specific to the client instance.