Spring Batch
  1. Spring Batch
  2. BATCH-377

Modify Jdbc ItemReaders to allow using a prepared statement.

    Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.0.0
    • Component/s: None
    • Labels:
      None

      Description

      All Jdbc ItemReaders use a string sql statement. However, there are many cases where JobParameters should be inserted to narrow the results. However, this requires String manipulation. PreparedStatements would be preferable. In the case of the cursor item reader this could perhaps be resolve with a PreparedStatementSetter, etc.

      There may be issues with this, but at a minimum, it should be investigated for 1.1. it's definitely out of scope for 1.0.0

        Activity

        Hide
        Lucas Ward added a comment -

        I went ahead and committed some code towards this issue. Almost every review I did with projects using Spring Batch had provided some kind of hacked way to implement this. I was a bit afraid that the fix might require an API change, so I worked through it. It was actually a surprisingly small change to the JdbcCursorItemReader. I added a setPreparedStatementSetter property, and changed the regular statement to a PreparedStatement. If no setter is provided it's not handed off.

        I also created a simple class: JobParametersPreparedStatementSetter. It's fairly straightforward, if you register it as a StepListener, and give it the names of the keys within the parameters that should be set as parameters, it will pull values from the JobParameters and set them on the PreparedStatement.

        I'm going to make the small change to allow the two key collector implementations to do the same and I'll mark the issue resolved.

        Show
        Lucas Ward added a comment - I went ahead and committed some code towards this issue. Almost every review I did with projects using Spring Batch had provided some kind of hacked way to implement this. I was a bit afraid that the fix might require an API change, so I worked through it. It was actually a surprisingly small change to the JdbcCursorItemReader. I added a setPreparedStatementSetter property, and changed the regular statement to a PreparedStatement. If no setter is provided it's not handed off. I also created a simple class: JobParametersPreparedStatementSetter. It's fairly straightforward, if you register it as a StepListener, and give it the names of the keys within the parameters that should be set as parameters, it will pull values from the JobParameters and set them on the PreparedStatement. I'm going to make the small change to allow the two key collector implementations to do the same and I'll mark the issue resolved.
        Hide
        Lucas Ward added a comment -

        I looked at providing the same approach for the Jdbc KeyCollectors, but it's not quite as straightforward, because the restartSql that's used in the single column case uses an object array. There may need to be a little more complex subclass of the single column version that requires a PreparedStatementSetter. I'll create a separate issue against 1.1 for that.

        Show
        Lucas Ward added a comment - I looked at providing the same approach for the Jdbc KeyCollectors, but it's not quite as straightforward, because the restartSql that's used in the single column case uses an object array. There may need to be a little more complex subclass of the single column version that requires a PreparedStatementSetter. I'll create a separate issue against 1.1 for that.
        Hide
        Dave Syer added a comment -

        Assume closed as resolved and released

        Show
        Dave Syer added a comment - Assume closed as resolved and released

          People

          • Assignee:
            Lucas Ward
            Reporter:
            Lucas Ward
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: