BeanPropertyRowMapper requires setters being present. Which is fine if you have some.

But if you only have a simple dto class for some reason, and want to make use of the mapper, it requires to create setters just for that.

It would be nice if we could have some DirectFieldRowMapper additionally, similar to: https://gist.github.com/stianl/6629122#file-directfieldrowmapper

Spring already allows direct field mapping for mvc with DataBinder.initDirectFieldAccess(). So why not providing a direct mapper also for jdbc beans, that can simply operate on public fields?

Comment From: sbrannen

Are you familiar with org.springframework.jdbc.core.DataClassRowMapper introduced in Spring Framework 5.3?

Does the "data class constructor with named parameters corresponding to column names" support meet your needs?

Comment From: membersound

No, as far as I understood the DataClassRowMapper only adds the ability to let the mapper create the object using a constructor. If you have a dto with public fields, you usually won't have a constructor matching all the fields.

Like, if the db row has 20 columns, you would have to introduce a 20 column constructor to make it work. This is no advantage over creating 20 setters.

Comment From: sbrannen

Like, if the db row has 20 columns, you would have to introduce a 20 column constructor to make it work. This is no advantage over creating 20 setters.

Sure. There's no real benefit in that.

Comment From: sbrannen

We've assigned this proposal to the 5.x Backlog for potential inclusion in 5.3.x

Comment From: membersound

Would still be great if that feature could get some investigation.

Comment From: jhoeller

I'm introducing a new SimplePropertyRowMapper with flexible constructor/property/field mapping in 6.1 now, used by the query(Class) method on JdbcClient (see #30931). Along the lines of our recent SimplePropertySqlParameterSource which is used for the paramSource(Object) method on JdbcClient, this provides a similarly designed fallback model for populating the target object which effectively supersedes DataClassRowMapper when no specific customization is needed.