You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, as far as I've found, the only way to specify a converter is by its type, e.g. via MappingMongoConverter or GenericConverter. I believe this is so Spring can generate code to map the objects more efficiently and avoid using reflection (and perhaps to make it compatible with native technologies like GraalVM?)
It would be helpful to be able to select a converter for an object based on custom annotations on the object's class.
Simple use case: Using Kotlin data classes as value types, I want to have a custom converter that will unwrap the fields and flatten them into the document, e.g. "username": "john.doe"
rather than "username": { "_class" : "com.mycompany.project.domain.value.Username", "value": "john.doe" }
Currently I have to register a custom converter for every one of the value types, or use a superclass and derive from that but that's clunky and then I can't use Kotlin's lovely data classes.
It would be much nicer to be able to have an annotation like @WrappedStringValue and a single converter class that could be applied to any object whose class had that annotation.
The conversion would need to be done using reflection, but if performance isn't a big issue then this is a clean way of doing this.
I know there is the @Embedded annotation that will be in the next release, but I don't love the API for that (nullable/empty options don't seem very applicable in Kotlin for non-nullable properties and immutable value objects with non-nullable values).
That was just a simple use case, but there must be many others out there for such a powerful mechanism for selecting converters.
If there is a better way to do what I'm talking about, or implement it with a simple customization of the MappingMongoConverter or ConversionService, I would love to know about it.
The text was updated successfully, but these errors were encountered:
Thanks for reaching out. This request is related to spring-projects/spring-data-commons#1484. We plan to investigate on converters that are bound to individual properties.
Currently, as far as I've found, the only way to specify a converter is by its type, e.g. via MappingMongoConverter or GenericConverter. I believe this is so Spring can generate code to map the objects more efficiently and avoid using reflection (and perhaps to make it compatible with native technologies like GraalVM?)
It would be helpful to be able to select a converter for an object based on custom annotations on the object's class.
Simple use case: Using Kotlin data classes as value types, I want to have a custom converter that will unwrap the fields and flatten them into the document, e.g.
"username": "john.doe"
rather than
"username": { "_class" : "com.mycompany.project.domain.value.Username", "value": "john.doe" }
Currently I have to register a custom converter for every one of the value types, or use a superclass and derive from that but that's clunky and then I can't use Kotlin's lovely data classes.
It would be much nicer to be able to have an annotation like
@WrappedStringValue
and a single converter class that could be applied to any object whose class had that annotation.The conversion would need to be done using reflection, but if performance isn't a big issue then this is a clean way of doing this.
I know there is the
@Embedded
annotation that will be in the next release, but I don't love the API for that (nullable/empty options don't seem very applicable in Kotlin for non-nullable properties and immutable value objects with non-nullable values).That was just a simple use case, but there must be many others out there for such a powerful mechanism for selecting converters.
If there is a better way to do what I'm talking about, or implement it with a simple customization of the MappingMongoConverter or ConversionService, I would love to know about it.
The text was updated successfully, but these errors were encountered: