[#BATCH-329] Make "VERSION" meaningful?

Spring Batch

Make "VERSION" meaningful?

Created: 30/Jan/08 04:38 AM Updated: 08/Mar/08 02:59 PM

Component/s:

Execution, Core

Affects Version/s:

1.0.0.m4

Fix Version/s:

1.0.0.rc1

Time Tracking:

Original Estimate:

0.25d

Remaining Estimate:

0.25d

Time Spent:

Not Specified

Description

« Hide

The version field in Entity and the corresponding VERSION field in the database schema doesn't seem to have any meaning right now. Where are these values supposed to come from? I can't seem to track it down in the code.

It would make sense for job instance to have the version number of the job config as defined by the user, and likewise for step / step config
I can't imagine what version would mean for the execution metadata... if it has the same meaning then it's redundant.

Or am I misunderstanding what the version field is supposed to mean?

All

Comments

Work Log

Change History

FishEye

Related Builds

Sort Order:

Ascending order - Click to sort in descending order

[ Permlink | « Hide ]

Robert Kasanicky - 30/Jan/08 06:05 AM

As far as I am aware this attribute is meant for optimistic locking support - so it has technical nature (rather than domain meaning).

[ Permlink | « Hide ]

Dave Syer - 30/Jan/08 09:26 AM

Yes, it's for optimistic locking. It's even used in the StepExecution. But not the other entities I think.

[ Permlink | « Hide ]

Douglas C. Kaminsky - 30/Jan/08 01:12 PM

That's not entirely clear from the name, in any case. As of m3, when I search the code, there isn't a single call to entity.getVersion() outside of tests and no mention of the VERSION field at all in the DAO classes except where it is set to zero for step executions.

Can you elaborate on what the indended purpose of this was? It seems like an incomplete thought at present.

[ Permlink | « Hide ]

Dave Syer - 06/Mar/08 07:23 AM

The Map dao should respect the same version update semantics as the SQL one if possible. And the JobExecution and JobInstance should have their versions updated by the daos as well.

[ Permlink | « Hide ]

Robert Kasanicky - 06/Mar/08 08:50 AM

I think version should be removed from JobInstance, given the semantics JobInstance = Job + JobParameters. JobInstance is fundamentally static data - just created, not updated.

For JobExecution I'm not sure whether we need the version - I suppose it is not expected to be updated concurrenlty.

[ Permlink | « Hide ]

Dave Syer - 06/Mar/08 09:41 AM

We might as well just use version for a static JobInstance then. Probably nothing to do there. The JobExecution should not be updated concurrently, so nothing fancy needed I think.

[ Permlink | « Hide ]

Robert Kasanicky - 08/Mar/08 02:59 PM

All daos now increment the version on save/update - only StepExecutionDaos test the value for concurrent modifications though