This commit adds a new method addProperty that allows for the dynamic addition of mapped properties to the existing map of properties. The method takes in the name of the property and its descriptor, and only adds the property if it has a write method. This allows for greater flexibility in mapping properties and enables subclasses to add properties dynamically as needed, extending the functionality of the parent class.

Comment From: sbrannen

Hi @giuseppemilicia,

Can you please describe a concrete use case for the proposed change?

Comment From: giuseppemilicia

Hi @sbrannen,

First of all, I would like to say thank you for the great work you're doing. It is a pleasure to learn from your contributions.

Regarding the addProperty method, it can be used to dynamically map properties of an object to database columns. One use case is to allow the use of custom annotations, such as @Column(name=""), which can be used to specify the column name that should be used for a particular field in the database table.

Comment From: snicoll

Thanks for the feedback. I wonder if BeanPropertyRowMapper is the good candidate for this. This class is really about mapping properties of a target class so I don't think that adding additional mappings dynamically is a proper use of this class.

You've described a use case, but I am afraid that I am not sure I totally got that. One way to ensure the use case is properly handled is to add a set of tests to the existing test suite to show in practice how that method should be used. Can you do that?

Comment From: giuseppemilicia

I've addressed your suggestion by adding a test case.

Comment From: jhoeller

I don't see such a free-form registration method as a good candidate for BeanPropertyRowMapper in terms of our intended design there. Instead, I rather envision a protected Set<String> mappedNames(PropertyDescriptor) template method which is being called for every PropertyDescriptor encountered on initialization, with the default implementation providing the traditional lower-case and underscore-based names. I've create a corresponding enhancement request for 6.1.4: #32199