support for custom job identifiers

Currently the database schema prescribes columns JOB_NAME, SCHEDULE_DATE, JOB_RUN, JOB_STREAM for job identification. Recently I've been told about a usecase where the job identifier is just a unique string generated by some external source. This seems reasonable, but doesn't fit into the current schema. The easy way to deal with this was to set the string as job_stream value,which was an unused property of ScheduledJobIdentifier, but this is obviously a hack.

It seems to me the job identification could be made more generic (e.g. a JOB_NAME and a single JOB_INSTANCE_IDENTIFIER string column) or it should be designed for customization (e.g. by putting the identification fields in a separate table and documenting that the definition of this table plus createJob() and findJob() dao methods are expected to be overriden - note that would leave orphaned STATUS column in job table).

One detail that supports this idea is that JOB_RUN and JOB_STREAM properties have no documentation and at least I am not certain what exactly they represent - has anybody really used them so far?

Are there more users who find the current job identification awkward/redundant for their needs or is the above just an exception?

Thanks

I think jobStream is almost intentionally undefined because I am not sure that it actually has a commonly accepted meaning. So I do not think it is a hack to use that field as a generated identifier - sounds perfect in fact.

I think what this example show is that ScheduledJobIdentifier is reallly a sort of dumping ground for ideas about JobIdentifier patterns. It was always the expectation that other implementations would be needed - either in the framework or in the field. I hope it isn't difficult for a project to extend the framework in this simple way, and we'd be interested in feedback from anyone who's tried it.

I think another implementation of JobIdentifier with just 2 String properties (instead of 1 in SimpleJobIdentifier) might be the answer, and I would have no qualms about using the JOB_STREAM column in the database to store the second String. Or maybe the column name could change.

http://opensource.atlassian.com/proj...owse/BATCH-195. Fixed by changing data model to use JOB_KEY (and removed JOB_RUN - not sure it was used anywhere, and the only interpretation I have heard is that it is actualy the JobExecution.id, so not part of the JobIdentifier at all). Please revert via JIRA if you think that is wrong.