I'm wanting to create a saved query with a variable, add that saved query to an app, and then trigger that query via a script while passing the variable to the query on trigger using additionalScope.
It appears this is not possible. My workaround is moving the query to the app (not using a saved query) like this:
You can see how the additionalScope UI shows up, compared to triggering the saved query in this example where it doesn't show:
This is also true if I use the GUI instead of SQL:
Hey @jonnilundy
I understand your issue,
You may prefer this forum for your question regarding additionalScope. I would be happy to assist you if you have more question about it.
Hello @jonnilundy,
When using a query from query library that 'id' property exists so that you can pass different values from different apps, since the goal of the query library is to make queries reusable. This differs from additionalScope because additionalScope is meant the pass different values inside the same app.
One thing that you can do is create a variable (for example dynamicID) and place it on the query library id input.
From then you just have to set its value before you trigger the query (change event handler to a run script on your component):
await dynamicID.setValue(3);
await deleteMusingById.trigger();
Hope this helps!
Hi Guilherme, just wanted to check something incidental in your example: are you sure the await is applicable for setValue()?
As far as I know, it doesn't return a Promise:
...unlike a Retool query, which does:
Using setValue in the context of a Retool JS Query has a special mechanism for synchronicity in the form of an Advanced setting:
But the "Run script" event handler — as you suggest in your example — has no such option.
The result is that the next line in your example (deleteMusingById.trigger()) could execute before setValue when used directly in an event handler script.
I'm not an expert in Promises or the minutiae of Retool's interplay in this regard, but I've encountered this situation and have been quite confused as a result. Basically if the expression passed to await doesn't evaluate to a Promise (or is not "then-able") the code execution occurs as normal, i.e. there's no "waiting".
Happy to be corrected though if I'm misunderstanding the situation!
Hey @jonnilundy! Thanks for reaching out.
While the workaround you've implemented is definitely functional, your original idea is a good one and works just fine. When defining any query, the Additional scope input is simply for clarity and suppressing linter errors, so the absence of it when importing a query from the Query Library is ultimately inconsequential.
I'm able to define and share a dynamic query via the Query Library.
I then set the dynamic input equal to a variable that will be provided via additionalScope.
And, last but not least, trigger the query with additionalScope.
I hope that helps!
