We migrated from Spring Batch 2.1.7 to Spring Batch 3.0.6, but got this jboss startup error:
org.springframework.jdbc.BadSqlGrammarException: PreparedStatementCallback; bad SQL grammar [SELECT E.JOB_EXECUTION_ID, E.START_TIME, E.END_TIME, E.STATUS, E.EXIT_CODE, E.EXIT_MESSAGE, E.CREATE_TIME, E.LAST_UPDATED, E.VERSION, E.JOB_INSTANCE_ID, E.JOB_CONFIGURATION_LOCATION from BATCH_JOB_EXECUTION E, BATCH_JOB_INSTANCE I where E.JOB_INSTANCE_ID=I.JOB_INSTANCE_ID and I.JOB_NAME=? and E.END_TIME is NULL order by E.JOB_EXECUTION_ID desc]; nested exception is java.sql.SQLSyntaxErrorException: ORA-00904: "E"."JOB_CONFIGURATION_LOCATION": invalid identifier
...which was apparently caused by Spring Batch 3 auto-migration, in which Spring Batch 3 has some table structure changes from Spring Batch 2.
To get things moving forward, using the create table script our developer team found in one of the Spring Batch jars, our DBA team wrote a script to update (instead of create) the tables, since we need the job history. This is all working so far, but here is our issue:
We can't migrate all our systems forward to Spring Batch 3. We have to leave the older ones in Spring Batch 2 for a while.
Are these Spring Batch 3 table structure changes backward compatible with Spring Batch 2?
They appear to be from analysis by our DBA team and from our batch run results so far, but I'm just asking if this was intentional by Spring, i.e. when Spring altered the table structure for the purposes of Spring Batch 3, did you INTENTIONALLY make it backward compatible?
So far they appear to be compatible, but I just want to make sure there isn't some subtle difference which will break our system badly down some not-often-used logic path, i.e. at statement execution time (vs jboss startup time).
Ben Ethridge