[GitHub] [superset] michael-s-molina commented on pull request #18181: fix: Explore long URL problem

[GitBox <gi...@apache.org>]

michael-s-molina commented on pull request #18181:
URL: https://github.com/apache/superset/pull/18181#issuecomment-1028885471


   > @michael-s-molina Thanks for working on this!
   > 
   > I noticed that when I open an Explore page, the URL will update with a new form data key every time I reload the page even when the form data isn't updated. Based on the PR summary, it seems this is by design, but I'm concerned this may not be scalable in high-traffic Superset deployments:
   > 
   > 1. If the cache is configured as FileSystemCache:
   >    
   >    1. In case `CACHE_THRESHOLD` is not set or is 0, this could quickly fill up disk space or degrade performance as number of files in the cache directory increases.
   >    2. In case `CACHE_THRESHOLD` is not zero, this could exhaust the allowed number of cache keys too fast, making it more likely that a link you shared to someone a while ago becomes invalid.
   > 2. It may be less of a concern if we configure the cache in Redis, but it's still not ideal (the cache keys still exhaust quicker than necessary if we configure Redis as [LRU cache](https://redis.io/topics/lru-cache), or require too much storage if we do not).
   > 
   > If the concern was that people opening the same key may accidentally override each other's explore state, how about we create a new key only when the cached data's `owner` is different than current user? The new key could be based on current key + visiting user id so it's always deterministic even when a user opens other people's shared URL multiple times.
   > 
   > What do you think?
   
   Hi @ktmud. That's a valid concern. This possible problem was also raised by @zhaoyongjie during the review and we decided to tackle it as a follow-up PR. I'm already working on it 😉 


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For additional commands, e-mail: notifications-help@superset.apache.org