History | Log In     View a printable version of the current page.  
Issue Details (XML | Word | Printable)

Key: BATCH-669
Type: Improvement Improvement
Status: Open Open
Priority: Minor Minor
Assignee: Unassigned
Reporter: Leon Noordermeer
Votes: 0
Watchers: 1
Operations

If you were logged in you would be able to see more operations.
Spring Batch

JdbcJobInstanceDao inserts 0L values instead of null values

Created: 18/Jun/08 06:29 AM   Updated: 18/Jun/08 01:14 PM
Component/s: Core
Affects Version/s: 1.1.0, 1.0.1, 1.0.0
Fix Version/s: None

Time Tracking:
Not Specified

Environment: any (windows / aix) on Oracle 10g


 Description  « Hide
It is unclear to me why JdbcJobInstanceDao inserts 0L values into the JOB_PARAMS table instead of NULL. This results, in example of a String parameter type, to the value 01 Jan 1970 in the column JOB_PARAMS.DATE_VAL, while it should be NULL. In my opinion the absence of an object is something different then a value of 0L.
The same goes voor the columns STRING_VAL, LONG_VAL, DOUBLE_VAL.

Example:
Actual code, line 142-144 of JdbcJobInstanceDao:
if (type == ParameterType.STRING) {
args = new Object[] { jobId, key, type, value, new Timestamp(0L), new Long(0), new Double(0) };
}

Fix:
if (type == ParameterType.STRING) {
args = new Object[] { jobId, key, type, value, null, null, null };
}



Mind that the schema allows null values.

 All   Comments   Work Log   Change History   FishEye   Related Builds      Sort Order: Ascending order - Click to sort in descending order
Dave Syer - 18/Jun/08 06:43 AM
Agreed in principle, but why do you really care? The TYPE_CD column tells you which value is significant anyway. We had some problems with some database platforms and driver combinations which mean that it is more robust to use "0" instead of NULL. I have a feeling that the problems were probably fixed in other ways, but I still prefer to take a cautious approach and not try and fix this, unless there are some strong opinions.

Leon Noordermeer - 18/Jun/08 01:14 PM
To be honest, I do not really care that much. It was an issue raised by our testing department stating the date in the column is confusing. I agree that the robustness of spring batch is more of an issue regarding issue BATCH-528.