BATCH-2478: Improve JdbcPagingItemReader ResultSet access

[Kuroshii]

Changes (within the context of JdbcPagingItemReader):

• Add logic for determining how to get an column from a result set based on the column name used in the query
• Add tests that the above changes allow for sortKeys with table-qualified names.

The problem I was made aware of, which is stated somewhat ambiguously in BATCH-2478, is that there is a difference between the name that JdbcPagingItemReader needs to refer to columns that it uses as sort keys and the name that is needed to retrieve that data from a result set.

This means you could have a perfectly formatted query constructed by the queryProvider that then fails because the JdbcPagingItemReader could not retrieve the values it needs to do paging from the ResultSet returned by the query.

I noticed a getSortKeysWithoutAliases method in AbstractSqlPagingQueryProvider, but I think that that approach isn't a very good solution to the problem.

Fundamentally, the problem is that sometimes what is used to refer to a column in the query may not match how it is referred to in the result set. The obvious case is when you have table qualified column names, but in some SQL engines (Postgres, for example) it is perfectly OK to have a '.' appear in an alias as long as the alias is quoted. This isn't a complete solution, because even still, some databases use the original column name in the ResultSet, even when you specify an alias in the query (HSQL, for example).

Some ideas for dealing with this more thoroughly:

• Parse the select clause for aliases and names of to determine which position in the result set to fetch the sort keys from. (Turn the name problem into a parsing problem).
• Have the client of JdbcPagingItemReader get sort key values from the ResultSet
• Have the client of JdbcPagingItemReader specify what names or positions in the original query correspond which sort keys.

[pivotal-issuemaster]

@Kuroshii Please sign the Contributor License Agreement!

Click here to manually synchronize the status of this Pull Request.

See the FAQ for frequently asked questions.

[pivotal-issuemaster]

@Kuroshii Thank you for signing the Contributor License Agreement!

[mminella]

I'm not a fan of testing this every time like this. Generating stack traces is pretty performance intensive. A better option would be to allow a Map<String, String> to be configurable to map any fields to the result set field. This allows it to be more flexible as well I think.

[Kuroshii]

@mminella Pull request updated; I think that should be a better solution