[Feature Request]: Default Resolver for Variables

[dsanderbi]

What would you like to happen?

It would be very useful to implement a default resolver. This resolver would allow specifying a default value to use in case a variable is not set.

Examples:

• ${my-var} not set → #{default-resolver:${my-var}:123} ⇒ 123
• ${my-var} set to 0 → #{default-resolver:${my-var}:123} ⇒ 0

Default value can itself be a variable:

• #{default-resolver:${my-var}:${my-var-default}}

Issue Priority

Priority: 2

Issue Component

Component: Hop Config, Component: Other

[mattcasters]

So like a parameter. I like the idea but have mixed feelings about the transparency and complexity to implement the parsing algorithm for nested variable expressions. Perhaps #{default-resolver:VARIABLE_NAME:default} could be a simple starting point. You could indicate in the resolver if you want to resolve default as a variable as well, but I don't know if that makes your projects easier or harder to maintain ;-)

[dsanderbi]

So like a parameter. I like the idea but have mixed feelings about the transparency and complexity to implement the parsing algorithm for nested variable expressions. Perhaps #{default-resolver:VARIABLE_NAME:default} could be a simple starting point. You could indicate in the resolver if you want to resolve default as a variable as well, but I don't know if that makes your projects easier or harder to maintain ;-)

Hi @mattcasters,

Thanks for the input yes, this is a viable approach. I implemented it as follows:

#{default-resolver:ETL_MODE;default-value:value}

Since the value corresponds to a column in the resolver, I need to provide both the default value and the variable that should be evaluated.

---

Since you have mixed feelings about the feature request, should we close the ticket? As the current resolver-pipeline shown above is a workaround that i can use.

[mattcasters]

Never close the ones with "mixed feelings", they are usually the most interesting.
But if we want default values, perhaps we can add another semi-colon option to ALL resolvers in the core functionality? That way you could say something like #{hashicorp-vault:edw:hostname:localhost}

[mattcasters]

With sufficient integration tests to validate previous functionality we could implement it here: https://github.com/apache/hop/blob/8ff5bd2c2b436b7ea41416c4fb260f4ae4c82780/core/src/main/java/org/apache/hop/core/variables/Variables.java#L165

[dsanderbi]

Never close the ones with "mixed feelings", they are usually the most interesting. But if we want default values, perhaps we can add another semi-colon option to ALL resolvers in the core functionality? That way you could say something like #{hashicorp-vault:edw:hostname:localhost}

If the semi-colon option is the way to go, we should consider to have the default as optional. It would be annoying for people to always set a default, if they do not want to set one.

[mattcasters]

Of-course optional. It should be easy to detect. Should we go for a default value or a variable to resolve, e.g. #{hashicorp-vault:edw:hostname-key:VAR_EDW_DEFAULT_HOSTNAME}?

[dsanderbi]

What would be the pros and cons of the two options?

[mattcasters]

Having a simple value as the default would probably solve most of the usecases and is simpler. Resolving a variable is more flexible but also requires more work (define another variable).

[dsanderbi]

If that’s the case, I would suggest NOT using the variable-based approach. An extension could still be added later if the community deems it necessary