Access to update counts in JdbcBatchItemWriter

[Jeff-Walker]

Expected Behavior

I'd like to have the ability to access the updateCounts array in the JdbcBatchItemWriter<>.
This could be easily done by extracting the "assert updates" portion of the write() method into a protected method.

protected void postProcess(int[] updateCounts) throws Exception {
  if (assertUpdates) {
    for (int i = 0; i < updateCounts.length; i++) {
      int value = updateCounts[i];
         if (value == 0) {
           throw new EmptyResultDataAccessException("Item " + i + " of " + updateCounts.length
               + " did not update any rows: [" + items.get(i) + "]", 1);
         }
       }
  }
}

Then, my class, using a class that tracks the facilities (my business object) that were updated and inserted could look like this.

@Override
protected void postProcess(int[] updateCounts) throws Exception {
  facilityTracker.addUpdated(Arrays.stream().sum());
  super.postProcess(updateCounts);
}

Current Behavior

Currently, the updateCounts array is a local variable in the write() method, and I'd have to totally reimplement the entire method to have access to it. Having a parallel implementation that could become out of date in subsequent releases of Spring Batch.

Context

I realize that this might be niche ask, but my batch program updates a table of "facilities" based on data received from another system. I have to keep track of how may were updated and inserted, etc., but right now I can only estimate based on the result from my ItemProcessor. My only other option is to totally reimplement the write() method, including the complex JDBC code.

Note

I can provide a PR soon for this if it has any chance of being committed.

[radmilagj]

Hi,
I would just like to know if there any updates regarding this issue?
Thanks!

[fmbenhassine]

@Jeff-Walker Thank you for opening this feature request. The update count is indeed inaccessible as of v5.0.2. We can make it accessible if this helps extending the class with such features and without having to reimplement the entire write method.

However, the suggested change might break the assertUpdate feature. Indeed, if someone extends the class, overrides postProcess and forgets to call super.postProcess(updateCounts);, the assertion is not applied if it is set to true. Moreover, the suggested method signature requires passing the chunk of items as parameter to be able to raise an EmptyResultDataAccessException and specify which item did not update any row, something like the following:

protected void postProcess(int[] updateCounts, final Chunk<? extends T> chunk) throws Exception {
  if (assertUpdates) {
    for (int i = 0; i < updateCounts.length; i++) {
      int value = updateCounts[i];
         if (value == 0) {
           throw new EmptyResultDataAccessException("Item " + i + " of " + updateCounts.length
               + " did not update any rows: [" + chunk.getItems().get(i) + "]", 1);
         }
       }
  }
}

Now the issue with this is that it gives reference to the chunk of items. If someone messes up with items here, she/he can break other features of the framework. For example, if someone accidentally adds or removes items from the chunk in this method, she/he would break the ChunkListener#afterWrite contract. (to be precise, we are safe against item removal as getItems returns a copy, but the addition is not safe).

So basically, the suggested way opens the class for extension, but does not prevent the modification of its internal behaviour. Do you agree?

Following the open/closed principle, I would minimize the scope of the extension point to the update count array, something like:

/**
 * Extension point to post process the update counts for each item.
 * @param updateCounts the array of update counts for each item
 */
protected void processUpdateCounts(int[] updateCounts) {
  // No Op
}

This method could be called at the end of the write method (outside the if (assertUpdates) { ... }) as it is independent from that feature. We have an open PR for this issue (#4339), I will discuss these details with the contributor there.