-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Revisit the default behaviour of job parameters conversion #3960
Comments
Any update on this, how to define the default parameter's format? |
@benas Is it possible to add a command line option like [
{
"job":"fooJob",
"parameters":[
{
"parameterName":"k1",
"parameterType":"String",
"paramter":"v1"
},
{
"parameterName":"k2",
"parameterType":"Long",
"paramter":123,
"identifying":true
}
]
}
] spring.batch.job.parameters.fooJob[0].parameterName=k1
spring.batch.job.parameters.fooJob[0].parameterType=String
spring.batch.job.parameters.fooJob[0].parameter=v1
spring.batch.job.parameters.fooJob[1].parameterName=k2
spring.batch.job.parameters.fooJob[1].parameterType=Long
spring.batch.job.parameters.fooJob[1].parameter=123
spring.batch.job.parameters.fooJob[1].identifying=true spring:
batch:
job:
parameters:
fooJob:
- parameterName: k1
parameterType: String
parameter: v1
- parameterName: k2
parameterType: Long
parameter: 123
identifying: true I think this format may be more friendly for Spring Boot users, compared with |
This commit also changes the way job parameters are parsed and persisted. NB: This commit should ideally have been split into two change sets. But the changes are tightly related that is was not possible to separate them. Related to: * spring-projects#3960 * spring-projects#2122 * spring-projects#1035 * spring-projects#1983
This commit also changes the way job parameters are parsed and persisted. NB: This commit should ideally have been split into two change sets. But the changes are tightly related that is was not possible to separate them. Related to: * spring-projects#3960 * spring-projects#2122 * spring-projects#1035 * spring-projects#1983
This commit also changes the way job parameters are parsed and persisted. NB: This commit should ideally have been split into two change sets. But the changes are tightly related that is was not possible to separate them. Related to: * spring-projects#3960 * spring-projects#2122 * spring-projects#1035 * spring-projects#1983
For some DB providers, columns cannot be named "VALUE". This commit adds a prefix where appropriate to the columns of `BATCH_JOB_EXECUTION_PARAMS`. Related to: * #3960
@lcmarvin Thank for your feedback and suggestion.
This could be a feature request for the The new notation has been implemented in #4204, which is explained in the migration guide and will be documented in |
FYI: The ERD at https://docs.spring.io/spring-batch/docs/current/reference/html/schema-appendix.html#metaDataSchema looks like it needs to be updated. |
Hi, I keep on searching when does these properties was deprecated: Any idea or references that I can check? |
The current behaviour of the
DefaultJobParametersConverter
has been confusing in many situations:parameter(type)=value
notation is not friendly to command line arguments and environment variables+
/-
prefixes is not friendly with Spring BootWhile it is possible to provide a custom
JobParametersConverter
and set it on theCommandLineJobRunner
orJobOperator
, I believe the default behaviour should be reviewed for a better getting started experience for batch users and a better integration with Spring Boot. Since this could be a breaking change, I see v5 as a good opportunity to revisit this part of the framework.References:
Related issues:
The text was updated successfully, but these errors were encountered: