Skip to content

Sanitizing csv batch items to use bool False instead of string False#111

Open
sgruber-seibert wants to merge 1 commit intomainfrom
input_validation
Open

Sanitizing csv batch items to use bool False instead of string False#111
sgruber-seibert wants to merge 1 commit intomainfrom
input_validation

Conversation

@sgruber-seibert
Copy link
Contributor

Sanitizing input values when using batch processing
"False" to False

@jpaul-seibert
Copy link
Contributor

jpaul-seibert commented Jan 29, 2026

I am not whether we like this to have. This converts Strings to Bool without asking, changing the behaviour of conditions. This might be intentional in most cases, but if someone relies on "whatever is the output, it becomes true", this could break the logic.

If you have Inputs like this, I see two possible ways to handle this:

  1. You use the always pipeline to convert variables to your needs. (already possible now)
  2. We introduce a syntax where you can specify the vartype, this could be something like "myvar=[:bool:]false" or similar. Good indicators for the vartype should be found, which are very unlikely to be there by accident. This feature can be even more powerfull, because it allows also other var types, which could reduce converting lines in the automatix scripts.

@sschmachtel
Copy link
Collaborator

While i would find this:
We introduce a syntax where you can specify the vartype, this could be something like "myvar=[:bool:]false" or similar. Good indicators for the vartype should be found, which are very unlikely to be there by accident. This feature can be even more powerfull, because it allows also other var types, which could reduce converting lines in the automatix scripts.
really good I'm afraid this would be complex to implement. But if it is easy, go ahead @sgruber-seibert

@sgruber-seibert
Copy link
Contributor Author

I am not whether we like this to have. This converts Strings to Bool without asking, changing the behaviour of conditions. This might be intentional in most cases, but if someone relies on "whatever is the output, it becomes true", this could break the logic.

If you have Inputs like this, I see two possible ways to handle this:

  1. You use the always pipeline to convert variables to your needs. (already possible now)
  2. We introduce a syntax where you can specify the vartype, this could be something like "myvar=[:bool:]false" or similar. Good indicators for the vartype should be found, which are very unlikely to be there by accident. This feature can be even more powerfull, because it allows also other var types, which could reduce converting lines in the automatix scripts.

If we introduce this syntax should we only add this to the vars-file or also to the --vars option ?
And if this is not set, should we default to strings as data type or throw an exception ?

@jpaul-seibert
Copy link
Contributor

I am not whether we like this to have. This converts Strings to Bool without asking, changing the behaviour of conditions. This might be intentional in most cases, but if someone relies on "whatever is the output, it becomes true", this could break the logic.
If you have Inputs like this, I see two possible ways to handle this:

  1. You use the always pipeline to convert variables to your needs. (already possible now)
  2. We introduce a syntax where you can specify the vartype, this could be something like "myvar=[:bool:]false" or similar. Good indicators for the vartype should be found, which are very unlikely to be there by accident. This feature can be even more powerfull, because it allows also other var types, which could reduce converting lines in the automatix scripts.

If we introduce this syntax should we only add this to the vars-file or also to the --vars option ? And if this is not set, should we default to strings as data type or throw an exception ?

I would say: string is the default and all variables are processed this way, whereever they come from. It could be a "hard" match, where the options are hardcoded. Alternatively it could be flexible and you just write the casting funktion there which is executed. This would be very powerful, but has also some risks.

@jpaul-seibert
Copy link
Contributor

jpaul-seibert commented Jan 29, 2026

While i would find this: We introduce a syntax where you can specify the vartype, this could be something like "myvar=[:bool:]false" or similar. Good indicators for the vartype should be found, which are very unlikely to be there by accident. This feature can be even more powerfull, because it allows also other var types, which could reduce converting lines in the automatix scripts. really good I'm afraid this would be complex to implement. But if it is easy, go ahead @sgruber-seibert

I don't think it's too complex. But there might be some little obstractles when we go in there in detail, especially to ensure, that only and exact that is converted, what you intend.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants