Hi together
I stepped on some Problem, for which i hope to find a solution here:
I want to show a Table (Module) for multiple users, which uses caching in its Query (1 input-parameter), BUT i want the Query to refresh itself, when the TTL of the Cache is greater than the Time-Diff between now and the lastRefresh in the Cache.
This is to prevent visiting the user 5 seconds before end of TTL and showing TTL-5 Seconds long the old results, so just to optimize the refreshing cycle of the table for the user.
Problem: With this approach all (e. g. 4) open Tables notice the TTL has run out and the cache is invalidated. So the query will start running 4 Times (saying taking 5 seconds each), because as it seems in the cache is not saved, if the query is beeing refreshed right now. It just seems to be noticed, after the first query finished and is validating the cache again.
Is it correct, that the current refreshing state is not saved in the cache so multiple parallel runs are not prevented? Or do i miss something?
So just to clarify, you want automatic run the query when the TTL is greater than the time difference between the current time and the last refresh.
So for example if the TTL is 10 seconds, the last refresh was 4 seconds before the current time and there is 6 seconds lefts on the cache's TTL, the refresh will occur.
How often do you want the cache to refresh while this above situation is the case?
But once the last refresh was 6 seconds before the current time, and there is only 4 seconds left on the TTL for the cache, it will no longer refresh. Correct?
Then for the second part of your question, you have 4 tables open at one time that are all trying to run refresh queries at the same time, right?
And you are saying that from the current app setup, that it appears the "cache is not saved"? Not sure what you mean by "It just seems to be noticed", could you elaborate on that?
To address the final question, you are asking if the app's current state is not being saved in the app's cache?
If you could help clarify so I can best help you that would be fantastic! Just a little confused, as it sounds like you have the first part working, but the issue with the second and third part is that your data is not changing to update the most recent queries that are being run to get new fresh data, correct?
Also here are the docs on caching, these will help to better explain how Retool caches query results and what controls user have over invalidating caching to replace old data with new data!
Hi @Jack_T, i painted the normal use of the dashboard in the following image. Say we are having the dashboard running on 3 Stations all around the warehouse.
We want to take advantage of the cache so have it activated (for simplicity the Cache-TTL and the refresh-duration of the Query are the same).
Station A starts the day and gets fresh data.
Station B starts about half the TTL later, so its shown data is outdated at about half of the time till its next refresh (black block above its lifecycle-block).
Station C starts just before the Query-Refresh from Station A, so its data is outdated pretty fast, almost its entire lifecycle (again the black block above its own lifecycle-block).
So in this setup we are hitting the server as less as possible, but we show a lot of outdated data.
So i replaced the query's automatic refresh by a "refresh-guard". This guard simple checks every second, if the queries TTL is reached, and if so, triggers the query, which will then hit the server.
This way we prevent outdated data, because as soon as the queries TTL is reached, the guard desires to refresh it.
The downside: it seems the cache itself isn't saving its current refresh-state. So Station A calls the Server and need 8 seconds.
Station B follows directly, because cache is invalid but can't see Station A handling the refresh already.
Same with Station C.
So instead of waiting for Station A's result and its write to the cache, all three are hitting the server.
I hope this makes it a little bit more understandable.
I admit this is some pretty edgy edgecase, but the possibility to check the cache for its current refresh-state (valid, invalid, idle_doing_refresh) would lead to an even better possibility to save resources.
If you desire i can build some example-module for you, which will show this exact case.
Sorry for the delayed reply I have been out of office.
Thank you so much for providing the greater details and the diagrams, these will help us a ton to understand the use case and work to craft a feature request!
I am thinking the feature request will cover adding a way to give cached query data a “Invalid but refreshing” status along with a timer to set for when this state should be triggered in conjunction with the refreshing query and corresponding cache invalidation
I believe you spoke with my team mate Kenny in further detail about this issue. It seems that this is something we can improve and appreciate the feedback!
I will keep you posted on the feature request and reply to this thread with any and all updates I get from the engineering team
