Custom RowMapper through bean definition not registering

[tcarlson25]

I have multiple domain aggregates using default row mappers. However, I have one that needs a custom row mapper. When attempting to register and use a custom row mapper for this certain domain through a bean definition of QueryMappingConfiguration, the row mapper is not used and still defaults to the default entity row mapper.
I created a row mapper class:

public class TestObjectRowMapper implements RowMapper<TestObject> {

    @Override
    public TestObject mapRow(ResultSet rs, int rowNum) throws SQLException {
        TestObject testObject = new TestObject();
        ...
        return testObject;
    }

}

as well as registering it in a bean of type QueryMappingConfiguration

@Bean
QueryMappingConfiguration rowMappers() {
    return new DefaultQueryMappingConfiguration()
            .registerRowMapper(TestObject.class, new TestObjectRowMapper());
}

According to the documentation, this should be a valid way of registering a row mapper. I want to avoid using the @Query annotation, as I will then have to override all of the existing findAll, findById methods in order to use my row mapper for those methods. Either I am missing something, or there is a bug in bean registration for row mappers.

Ideally, custom row mappers should work with methods inherited from extending CrudRepository/PagingAndSortingRepository as well as custom methods. Thanks in advance.

[schauder]

QueryMappingConfiguration is intended for custom queries only.
Interesting idea to apply it to the methods of the predefined methods as well.

Could you explain why you need a custom RowMapper for the aggregate?
So we can come up with an alternative solution or better understand why this would be a valuable feature.

When you can use the standard query, I would expect that you could use custom constructor instead.

[tcarlson25]

If there are instances where an aggregate has columns in the database that are complex, such as a json file that is a representation of another object, my options would be:

1. have the aggregate represent that column as a String which holds the json. A getter and setter can be applied to deserialize that json to its type.
2. have the aggregate represent that column as the actual object type that it is. But this would require a custom row mapper in order to take the column input and map it appropriately before creating the aggregate.

If I were to choose option 2, I would want the row mapper to also be able to be applied to default methods such as findAll, findById, etc.

[schauder]

Can't you do the same with a custom conversion for the column/type?

[tcarlson25]

As my understanding (correct me if I am wrong), if I use reading/writing converters, that would apply to every field with that type in the database, which I do not want. For example: if I had a reading converter that maps a String to a Person Object, wouldn't that try to map every varchar in the database to a Person object? I do not see anywhere in the documentation that specifies a way to register a converter only for a specific table and column.

[schauder]

This is handled by @ReadingConverter and @WritingConverter.
Let's say you have a @WritingConverter from Person to String and a @ReadingConverter in for the inverse conversion.

The writing converter would be applied to every Person in you domain model and thereby a Person could be stored in a VARCHAR field.

The reading converter would be used for values that are of type String, when loaded from the database and belong to a property of type Person. Other properties that already are of type String or some completely different type (WaterBottle) would be completely unaffected.

In many cases this should do the trick. If you have Person instances in your model that should get converted to a String and other Person instances you want to store as Numbers you would be out of luck right now.

Does that solve your problem?