Determine approach for handling file creation/update in restart scenarios [BATCH-8] about spring-batch HOT 6 CLOSED

Attila Balga commented

This issue is closely related to issues BATCH-16 and BATCH-21.

There are primarily 2 things to solve:

1. how to design file handling

   • 3 solutions identified by us:
     a. Use FileUtils class: this utility class is not extendable, contains a static method handling file creation/update.
     This solution is currently implemented.
     b. Redesign FileUtils as an abstract class - AbstractFileOutputSource:
     all FileOutputSource classes like StaxFileOutputSource and FlatFileOutputsource will extend this class.
     A possible problem might be that all the file input sources will inherit the same implementation when it is in place,
     even if they do not need it, or the needed handling strategy might sometimes vary between particular sources.
     c. Use the strategy pattern - the file handling concerns will be accessed through a strategy interface using a default injected
     implementation from a strategy host class into the particular output sources
     (Joshua Bloch, Effective Java, Programming Language Guide, July 2005, pg.115).

   A resource wrapper - like it exists in the SplittableFlatFileOutputSource might implement a strategy of choosing a right output file name,
   so for an implicit case a user do not need to bother with it.

2. what kind of functionality will be supported

   • a setUpOutputFile method will handle flags:
     a. restarted
     b. overwriteOutputFile
     c. generateUniqueFileName

   Handling of a restartable job is already solved.
   For a non restartable one there are 2 possibilities - at restart if file exists and overwriteOutputFile is false:
   aa. throw an exception if generateNewFileName is false
   bb. create a file with a new filename using strategy in the resource wrapper (use timestamp)
   For overwriteOutputFile = true the output file will be just overwritten as for restartable jobs.

from spring-batch.

Attila Balga commented

Sorry for the formatting, the JIRA screwed the spacing up a bit after submit.

from spring-batch.

Lucas Ward commented

This issue is pretty well handled in the current release. The only major refactorings that could happen would require too big of changes for 1.1, so I'm moving to 2.0.

from spring-batch.

Robert Kasanicky commented

'Approach has been determined' long ago and is implemented consistently using the FileUtils class - I don't think we need to do anything more here.

from spring-batch.

Robert Kasanicky commented

reassigned for review

from spring-batch.

Lucas Ward commented

I agree, closing.

from spring-batch.