Skip to content

Select converter based on custom annotation rather than object class #3596

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
mpittkin opened this issue Mar 16, 2021 · 1 comment
Closed
Assignees
Labels
type: enhancement A general enhancement

Comments

@mpittkin
Copy link

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.

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Mar 16, 2021
@mp911de
Copy link
Member

mp911de commented Mar 17, 2021

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.

@mp911de mp911de added type: enhancement A general enhancement and removed status: waiting-for-triage An issue we've not yet triaged labels Mar 17, 2021
mp911de pushed a commit that referenced this issue Mar 21, 2022
mp911de added a commit that referenced this issue Mar 21, 2022
Reformat code. Tweak documentation wording.

See #3596
Original pull request: #3982.
mp911de added a commit that referenced this issue Mar 21, 2022
Reformat code. Tweak documentation wording.

See #3596
Original pull request: #3982.
@mp911de mp911de added this to the 3.4 M4 (2021.2.0) milestone Mar 21, 2022
@mp911de mp911de linked a pull request Mar 21, 2022 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: enhancement A general enhancement
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants