-
Notifications
You must be signed in to change notification settings - Fork 328
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
[Feature Request]: An improved method to resolve variable expressions #3454
Comments
+1 on prefixing, at least for the provider (AES/ENCRYPTED/MYVAULT). As for the resolving of nested variables, I lean towards making the default way to handle variables and keep the syntax simple/optional. I see something like this working (just thinking out loud): ${MY_VARIALBE} -> full nested lookup ${AES:MY_VARIABLE} -> full nested with AES provider |
The counter argument that I saw was that in development you might just want to use clear-text passwords and in production secrets are stored in a vault. Mind you, I'm not opposed to the prefixes. I just think that having this 'symbolic link' functionality could be cool to have as well. |
For any environment you're in it would be cool to have a 'symbolic link' feature for variables.
|
If we have variable nesting working your variable in the pipeline/database metadata can be ${MY_VARIABLE} and in the environment in development it would be "my cleartext password" in production it could be ${vault:secret}. This way you can hit both birds with one stone :) |
Yes indeed. One the one hand you want some sane defaults, nothing too much to configure, just to get some basic functionality like nested resolution. On the other hand we'll have users who need a bit of extra hand-holding to configure vault access or which pipeline to execute to get a value. |
Question remains that we need a place to store the environment configuration metadata. |
Sorry for the stupid question but what do we intend by variable's depth? That is not clear to me |
for example you can have a variable that is ${MY_VARIABLE} but that variable could be configured in the environment with a value of ${MY_OTHER_VARIABLE} which could then be specified in hop-config as ${HOP_CONFIG_FOLDER} so then it goed 2 variables deep |
Cristal clear thanks for the explanation |
I was thinking about a simple generic plugin type to do a value lookup. The lookup could apply to one or more types (variables in our case) and have to be ability to return either a single value or a list. |
Sharing my perspective as a devoted user with a deep appreciation for your work on Hop:
|
Great points Dennis. I guess I'm more concerned with backward compatibility. I'm thinking specifically about the people that built around the current limitations of variable replacement. |
So the plot thickens. I was writing a few extra unit tests for |
Then in this case it might be an error I introduced in the PROJECT_HOME extension point. I will take a look |
That doesn't mean the other ideas aren't valid. Working with a prefix does show the intent of the variable replacement clearly. |
The idea to have a new 'Lookup' plugin type in core is meant to allow all plugins to contribute and use without too many class loader issues. It also allows us to integrate with metadata. |
Does this mean if we are setting a variable in a transform "Set Variables", if we put ${AES:MY_STRING} that the step would interpret that to be "Use AES to encrypt the string when setting the value from the stream." If on the other hand we were using a Get Variables transform and used ${AES:MY_STRING}, should we expect clear text to come out from an encrypted value? Is this just metadata? (encrypted_yn, and encryption_used = 'AES')? |
@usbrandon Variable expressions are basically used to look up a value somewhere. Setting a value in a Hop context can either be a clear text value or indeed another variable expression like the one you mentioned. No encoding or decoding is done at the time of setting the variable, only when the variable expression is decoded and the actual value is looked up. The results of the lookup are in most cases indeed a clear text value since that's what the transform, action or metadata element needs at runtime. |
What would you like to happen?
Right now, if we have a variable expression, for example
${MY_VARIABLE}
, any value that we have on the books forMY_VARIABLE
in the localIVariables
instance will be substituted and returned duringIVariables.resolve()
.The API that is used
StringUtil.substitute()
already supports recursive or nested variable resolution. However, this method is not used anywhere right now.It would be great if we could give Hop users a way to signal that recursive or nested substitution of variables should take place. Some suggestions come to mind:
$(MY_VARIABLE)
${NESTED(2):MY_VARIABLE}
, for example to resolve the variable 2 levels deep.If we think about the second prefixing system we can even think of a pluggable, configurable, system which would allow us to do more than just nested variables. For example we could build a
${ENCODED:DATABASE_USER}
, for example if you want to obfuscate or encrypt the username of a database (not just its password) in an environment properties file.We could combine prefixes, for example:
${ENCODED(EAS2):NESTED(1):MY_VARIABLE}
.Other ideas are ways to get values from a secrets vault or resolve a value from a certain web-service.
The counter argument to all this is that it's a very cryptic way of doing things. Even as I'm typing this I'm not liking it.
Perhaps we can think of a pluggable system attached to the lifecycle environment in which we're allowing these options for variables. That way we can build proper user interfaces reflected in proper configuration files and metadata.
Issue Priority
Priority: 3
Issue Component
Component: API
The text was updated successfully, but these errors were encountered: