Wayne Lund added a comment - 27/Jul/07 03:54 PM

Wayne Lund added a comment - 27/Jul/07 03:54 PM I talked with Lucas at some length trying to get context for what this issue was about so hopefully my response is on topic. I'm not comfortable having JobStream and JobRun as optional properties unless we're discussing only the ability to extend the default schema. We did a lot of research on batch schemas when we were surveying batch projects and found that even though the names varied that the meanings were common. This was over ~four projects, which is hardly exhaustive but gave us at least a feeling about what's common. However, I do agree that a ScheduledJob has different attributes than a TriggeredImmediately or what we called an "On-Demand" job. It seems like have a small hierarchy (e.g. JobInterface, Job - handles on-demand, and ScheduledJob) can model capture the different needs in what information is stored about the job. For example, an on-demand job needs to only start its start and end times and not its scheduled start and other required information for scheduled jobs. I believe that projects would rather start from a common schema with a way to enhance then simply being handed a map to fill up with user defined properties.

Dave Syer added a comment - 29/Jul/07 10:51 AM

Dave Syer added a comment - 29/Jul/07 10:51 AM I think when JobRuntimeInformation was first designed it was supposed to solve this problem: an extensible identity for a Job instance. We lost sight of that, and JobRuntimeInformation is now pretty useless (see BATCH-31), mainly because it has no persistence strategy of its own - only a factory. I think that strand needs to be picked up again - JobRuntimeInformation is really JobIdentity, and it needs an extensible Dao of its own. We can provide more than one implementation of the JobIdentity and JobIdentityDao out of the box - I think that's the hierarchy that Wayne is taling about. Then the scheduleDate crowd will have something that works for them, but is only one implementation of a strategy for JobIdentity.

Dave Syer added a comment - 03/Aug/07 06:42 AM

Dave Syer added a comment - 03/Aug/07 06:42 AM JobInstance (formerly known as Job) has very little information that is not an "identifier". There is a surrogate key and a status. The rest could be abstracted into an interface JobIdentifier (replacing JobRuntimeInformation) with implementations having optional properties like scheduleDate and jobStream. The basic interface needs only a name property (matching the job configuration) and a label (or something), which makes the instance unique in the absence of any other properties in the implementation. I actually start to warm to Hibernate annotations at this point (Java 5 only unfortunately) because the implementation of JobIdentifier could map itself with no changes to any other code, giving maximum flexibility for projects. With XML mapping it only works out of the box with no changes if JobIdentifier is an Entity (yuck - it just isn't) and the mapping file can be overridden (not sure how that would work). With SQL it is more straightforward - but less pleasant because the client has to provide an additional Dao for the identifier.

Dave Syer added a comment - 05/Aug/07 08:53 AM

Dave Syer added a comment - 05/Aug/07 08:53 AM One approach that will work with Java 2 and XML mapping and with the SQL daos is a Properties-JobIdentifier conversion strategy like with RestartData. I'm going to see if that is practical (and address BATCH-31 at the same time).

Dave Syer added a comment - 05/Aug/07 09:48 AM

Dave Syer added a comment - 05/Aug/07 09:48 AM Created JobIdentifer interface (replacement for JobRuntimeInformation). TODO: the daos still assume they are getting a JobRuntimeInformation (or rather a ScheduledJobIdentifier).

Dave Syer added a comment - 05/Aug/07 11:22 AM

Dave Syer added a comment - 05/Aug/07 11:22 AM JobInstance now has a JobIdentifier - the DAOs are still tied to the old style specific implementation.

Dave Syer added a comment - 28/Aug/07 05:37 AM - edited

Dave Syer added a comment - 28/Aug/07 05:37 AM - edited Added a subclass mapping to JobInstance in the Hibernate case that copes with JobIdentifier strategies SimpleJobIdentifier and ScheduledJobIdentifier. Once the Jdbc case works we can close this for the present - until more JobIdentifiers are needed (e.g. for BATCH-84).

Dave Syer added a comment - 28/Aug/07 06:27 AM

Dave Syer added a comment - 28/Aug/07 06:27 AM Sql and Hibernate JobDao implementations are now able to cope with Simple- and ScheduledJobIdentifier strategies. There is also a JobIdentifierFactory for each one. When more are needed we might need a new extension point to simplify the Jdbc case. Hibernate can probably always work with the EntityNameInterceptor.

Dave Syer added a comment - 07/Aug/08 10:06 AM

Dave Syer added a comment - 07/Aug/08 10:06 AM Assume closed as resolved and released