Bug 4578

Summary: JobOperator.getJobInstances() ordering? zero-based vs. one-based
Product: jbatch Reporter: ScottKurz
Component: sourceAssignee: cvignola
Status: RESOLVED FIXED    
Severity: minor CC: issues, mminella
Priority: P5    
Version: 1   
Target Milestone: ---   
Hardware: PC   
OS: Windows   
Whiteboard:

Description ScottKurz 2013-01-21 22:07:30 UTC
For:
List<JobInstance> getJobInstances(String jobName, int start, int count

Two things:

the Javadoc currently states: 

* @param start
* specifies the relative starting number to return from the
* maximal list of job instances.

1) Probably should be clear that 'start' is zero-based rather than one-based.

2) If a specific order is intended (e.g. start=0 corresponds to the first JobInstance and the List is in order of time of JobInstance created ... then this should be stated in the spec.    Otherwise an implementation is free to use a "random" order or also to pick the reverse order (most recent corresponds to start=0).
Comment 1 mminella 2013-01-28 18:56:29 UTC
There is an issue with number two here.  We can't order JobInstances in chronological order since the JobInstance does not have any type of creation date (and really doesn't have much of a use for one).  The best we could do is go by the first execution date, but that seems messy.  The reason Spring Batch can guarantee the order is that we also control the layout of the repository (we require the use of sequences in the repository so we can order by that).  The spec does have that type of control since we did not provide any specifics on the underlying repository implementation.  I would recommend not providing an order guarantee on the instances.