This is a follow-on to closed ticket (that I'm unable to reopen) which I believe did not fully address the problem.

After the update the BeanPropertyRowMapper's behavior still does not match the documentation from BeanPropertyRowMapper which states:

The names are matched either directly or by transforming a name separating the parts with underscores to the same name using "camel" case.

The "directly" part of the mapping does not occur. Instead it only attempts to match fully lower-cased values.

Given data class:

data class MyClass(
    @Id
    val someId: Long?,
    val fooValue String?,
    val barValue: String?,
    val updateTimestamp: LocalDateTime?
)

and query:

SELECT someId, fooValue, barValue, updateTimestamp FROM ...

the fields are not mapped.

Mapping happens successfully if either the query is changed to:

SELECT someId as some_id, fooValue as foo_value, barValue as bar_value, updateTimestamp as update_timestamp FROM ...

OR the data class is changed to:

data class MyClass(
    @Id
    val someid: Long?,
    val foovalue String?,
    val barvalue: String?,
    val updatetimestamp: LocalDateTime?
)

It seems either the documentation or the behavior of this class should be changed.

Comment From: sbrannen

@madorb, what databases (and database drivers) did you test this against?

In addition, are you using a connection pool, and if so which one(s)?

I ask, because I believe the behavior of java.sql.ResultSet.findColumn(String) may be dependent on your exact setup.

If you could provide a minimal example application which demonstrates the problem, that would really help us in diagnosing the issue.

Comment From: madorb

This was SQL server, i haven't touched this project for a while, but if i can find the time i'll try to get a minimal example

Comment From: sbrannen

Thanks for the reply, @madorb.

This was SQL server,

Based on a quick glance at the implementation of the JDBC driver for SQL server, it appears that column name lookups are performed as exact matches and then case-insensitive as a fallback.

In light of that, it is a bit unexpected that foovalue would not return a positive match for fooValue; however, we really need a reproducer to analyze exactly what it going on.

i haven't touched this project for a while, but if i can find the time i'll try to get a minimal example

That would be great.

the fields are not mapped.

As a side note, what exactly do you mean by that?

Was there an actual error -- for example, in the form of an SQLException?

Or did the DataClassRowMapper complete its mapping without actually mapping values to the constructor arguments in your data class?

Comment From: spring-projects-issues

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

Comment From: spring-projects-issues

Closing due to lack of requested feedback. If you would like us to look at this issue, please provide the requested information and we will re-open the issue.