Bson-kotlin #1093
Bson-kotlin #1093
Conversation
Library adds Bson support for Kotlin data classes Follows the spirit of the bson-record-codec library JAVA-4872
| import org.bson.codecs.pojo.annotations.BsonRepresentation | ||
| import org.bson.diagnostics.Loggers | ||
|
|
||
| internal data class DataClassCodec<T : Any>( |
There was a problem hiding this comment.
You chose to restrict the classes supported by the codec to kotlin data classes. You will have feature request about sealed class support (often used in kotlin & supported in kmongo). Enums are already supported with the java codec.
There was a problem hiding this comment.
Thanks - that can definitely be added to the backlog. We support sealed classes in Scala.
| types: List<Type> = emptyList() | ||
| ): DataClassCodec<R> { | ||
| validateAnnotations(kClass) | ||
| val primaryConstructor = kClass.primaryConstructor!! |
There was a problem hiding this comment.
usually I prefer to write: kClass.primaryConstructor ?: error("no primary constructor for $kClass")
(avoid !!)
| parameter.findAnnotation<BsonProperty>()!!.value | ||
| } else { | ||
| requireNotNull(parameter.name) | ||
| } |
There was a problem hiding this comment.
It's more idiomatic to write
return if (parameter.hasAnnotation()) {
idFieldName
} else {
parameter.findAnnotation()?.value ?: requireNotNull(parameter.name)
}
| new ExpressionCodecProvider(), | ||
| new Jep395RecordCodecProvider())); | ||
| new Jep395RecordCodecProvider(), | ||
| new KotlinDataClassCodecProvider())); |
There was a problem hiding this comment.
There is an issue here for the migration of kmongo: this is not backward compatible - and it prevents to add easily other kotlin codecs for data classes. I had to define my own default settings in kmongo because of an issue with EnumCodec (see https://github.com/Litote/kmongo/blob/master/kmongo-shared/src/main/kotlin/org/litote/kmongo/util/KMongoUtil.kt#L110 )
I would be great to add a way to configure the list of default CodecProviders (ServiceLoader ?)
By the way, you forget to update the javadoc of #getDefaultCodecRegistry()
There was a problem hiding this comment.
Extending codec registries is supported, either via MongoClientSettings or using withCodecRegistry. As they are registries, they are order dependent so users typically do something like: fromRegistries(fromCodecs(myCustomCodec), DefaultCodecRegsitry)
Will update the javadoc.
There was a problem hiding this comment.
Ok thank you. The issue with kmongo is that I have a codec to add at the end of the list of default providers - but I can manage that by removing EnumCodecProvider & KotlinDataClassCodecProvider ;)
| codec.encode(writer, value, EncoderContext.builder().build()) | ||
| assertEquals(expected, document) | ||
| if (expected.contains("_id")) { | ||
| assertEquals("_id", document.firstKey) |
There was a problem hiding this comment.
Just curious: why is it important for the first key to be _id?
There was a problem hiding this comment.
It's a micro-optimization that drivers do, since the server needs the _id value right off, and due to BSON structure it has to look for keys sequentially.
| new ExpressionCodecProvider(), | ||
| new Jep395RecordCodecProvider())); | ||
| new Jep395RecordCodecProvider(), | ||
| new KotlinDataClassCodecProvider())); |
| codec.encode(writer, value, EncoderContext.builder().build()) | ||
| assertEquals(expected, document) | ||
| if (expected.contains("_id")) { | ||
| assertEquals("_id", document.firstKey) |
There was a problem hiding this comment.
It's a micro-optimization that drivers do, since the server needs the _id value right off, and due to BSON structure it has to look for keys sequentially.
|
Manually rebased and merged. |
4 participants
Library adds Bson support for Kotlin data classes
Follows the spirit of the bson-record-codec library
JAVA-4872