I'm using retool database and enabled caching. I'm using invalidateCache() for queries when I expect new data to have been added to the database.
However, I get mixed results. Is it that the query is cached based on the actual query or is it cached as a resource?
I have filters and other variables in the query using {{ ... }}. So could it be that not the right query is being invalidated but just a variation of the query due to selected filters?
Hey @Steven_W! Thanks for reaching out. This is a great question and an opportunity to clarify the way query caching works.
Cached response data is stored using Redis, whenever possible, and is associated with a unique key. That key is generated based on a few different inputs - the query's UUID, base URL, params, and headers. This means that even one query can have a whole bunch of cached variants.
Calling invalidateCache on a given query should clear the cache of all records that are associated with that particular query's UUID. This means that it wouldn't have any affect on otherwise identical queries defined in different apps, given the fact that they have different UUIDs.
I'm not sure if that explains the variation that you're observing, in particular, but hopefully it's useful! If you think you might be seeing buggy behavior, feel free to share your app JSON here. 
In that case, storing a query in the query library would not have any effect on this. Am I right? If 2 different apps use the same query, it’s cached 2 times and when one is invalidated, the other is not.
With params, do you mean page/app parameters or query params/variables?
Say I have toggle true/false and I use that {{toggle.value}} in the params/variable of a retool database query.. will the true and false state of that toggle create two unique UUIDs?
And what if we don’t use a param section but directly referenced in query like WHERE archived ={{toggle.value}} ?
Correct - the same principle applies to a query that is defined in a module and then inserted into multiple apps.
Query params/variables, which include the value of any variables that are being interpolated into the text of a SQL query. These different variations should all share the same query UUID, though, meaning their caches will all be invalidated simultaneously.
Then I don’t know why I get old results or missing new results. Could it be that I have to chain the query to the invalidateCache() ? If it works like a promise then that could cause issues.
