spring-data-mongodb
spring-data-mongodb copied to clipboard
Handling collections and map types before running an element converter
When the custom conversions are checked before collection and map converters, it is not possible to use custom converters for lists and maps.
If a custom converter for a list or a map is defined, it is executed here and not from within the collectionConverter
where it should be executed.
So I think collections and maps should be handled beforehand.
Maybe lines 2064-2066 might not be needed ad all as this case is covered with line 2081.
@nexx512 Please sign the Contributor License Agreement!
Click here to manually synchronize the status of this Pull Request.
See the FAQ for frequently asked questions.
@nexx512 Thank you for signing the Contributor License Agreement!
I extendend this functionality to cover lists and maps of custom types, even allowing for collection converters whose target is not a collection. Being not so restrictive leaved more options to the user to implement custom converters.
It should now be possible to map vavr lists and maps with a simple converter like
@ReadingConverter
public ListReadingConverter implements Converter<List<ListType>, io.vavr.collection.List<ListType>> {
@Override
public io.vavr.collection.List<ListType> convert(List<ListType> source) {
return io.vavr.collection.List.ofAll(source);
}
}
However for maps to work correctly, the change from https://github.com/spring-projects/spring-data-commons/pull/2517 is required.
I also removed some mapping tests that tested a mapping with a class extending java.util.Map
. The extending class however didn't expose a map like interface. So i would say that this case should be covered by a separate class containing a map instead of extending one. This pretty much looked like a good example where aggregation should be preferred over inheritance.
Would be great if someone can have a look at it and discuss it if there are concerns.
Relates to spring-projects/spring-data-commons#2511.