According to the explanation in this post (very nice insight, thanks!), an element featuring e.g. a dynamic/variable SQL transformation on a source, should still feature caching. However, this does not seem to be the case. The example app fetches the data each time I switch the query.
Unfortunately, the cache is actively invalidated if the datasource-config or the sourceOptions of the element change (the latter is the case for you).
Thanks @max.toball. I am still a bit confused, though. Could you help resolving the conflict in my understanding:
- transformations are contained in the cache keys
- when a transformations changes via variable, that invalidates the cache (is there another way of change?)
Yes, the transformations are in the cache key, so flipping back and forth between different transformations managed by the app (as you do when adding and removing filters for example) will result in cache hits. However, as we can’t really predict what effects the change of variables in the app configuration has, we invalidate all of the element’s cache when either the datasource config or the sourceOptions of the element change.
Think for example of using a variable in the dataId-part of a datasource. Changing that means you potentially target an entirely different dataset, so the cache needs to be invalidated or we would still show the same data as before. For sourceOptions it’s the same. This could be done more selectively indeed. Alternatively, the datasource-config as well as the sourceOptions could also go into the cache key. Maybe that could be a feature request.
Other things that actively invalidate the cache:
- Data update received from backend
- Table edited and saved
- When the endpoint filling a dynamic source is re-executed
There’s potentially more.
1 Like