You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It's rather a feature request or maybe I'm missing something in the docs.
I quite often need to have different behaviour for new DBs vs existing ones. Thus, we leveraged the User Tokens feature which is great but scripts having such tokens are persisted to RH tables with tokens replaced which makes it impossible to use such scripts in 20.up at least in my scenario.
What I would like to have in RH is to be able to tell that tokens should not be replaced before storing them to DB. I'd say the ultimate goal would be to define it at the token level.
The text was updated successfully, but these errors were encountered:
This is an interesting idea. But, it does imply that you never want to run the script again if you change the tokens. I myself do not use the token replacement feature a lot, so I don't know what the most usual scenarios are.
How would you imagine to be able to specify this at a token level? Any ideas?
The most flexible implementation I can imagine is introducing a new parameter holding the list of nonpersistable tokens. There could be two "special" values - ALL and NONE - to apply a universal strategy for all or none of tokens.
Another options which I'm personally fine with is just a boolean flag to wether persist or not token values. But, apparently, it's less flexible.
It's rather a feature request or maybe I'm missing something in the docs.
I quite often need to have different behaviour for new DBs vs existing ones. Thus, we leveraged the User Tokens feature which is great but scripts having such tokens are persisted to RH tables with tokens replaced which makes it impossible to use such scripts in 20.up at least in my scenario.
What I would like to have in RH is to be able to tell that tokens should not be replaced before storing them to DB. I'd say the ultimate goal would be to define it at the token level.
The text was updated successfully, but these errors were encountered: