You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@superset.apache.org by GitBox <gi...@apache.org> on 2022/02/17 10:37:34 UTC

[GitHub] [superset] villebro edited a comment on pull request #18181: fix: Explore long URL problem

villebro edited a comment on pull request #18181:
URL: https://github.com/apache/superset/pull/18181#issuecomment-1042796781


   @ktmud I like the idea of defaulting to SimpleCache for debug mode and NullCache for other modes. I suggest we make that change asap; any objections if I open a PR for that?
   
   With regards to persisting "critical" key-value pairs such filter/form data state, it's good to keep in mind that a shared link that hasn't been accessed within a set timeframe, say 3 months from now which is the default for the dashboard filter state, most likely won't be accessed 6 months from now, or ever (adjusting this according to own tolerances is very simple). Also, as chart/dashboard state has a tendency of evolving over time, I'm not sure being able to rehydrate state that is years old is usually very useful. Keeping in mind, though, that links that are regularly accessed will not expire (see `REFRESH_TIMEOUT_ON_RETRIEVAL` in the codebase; this can also be disabled if needed).
   
   However, a potential solution that ensures critical state is persisted beyond the cache timeout and is resilient to the cache being accidentally flushed could be as follows:
   - Dashboard/Explore state continues to be persisted in the cache as is currently done.
   - We rename the current "Copy dashboard/chart URL" and related buttons to something like "Share permanent link" and persist this state in the metadata database, not the cache. When this link is accessed, the data is fetched from the metadata database, and after that the URL is updated to again reference a cached key, so that the state is again maintained in the cache. And if the user then wants to reshare the updated state, they click on the button again. Etc etc.
    
   This approach should be very easy to implement and would give us the best of both worlds: temporary state that's needed during regular use would still be stored in the cache, and users could keep sharing URLs directly from the address bar that expire automatically (also from the cache). And if they really want to make sure the link never expires, they could just click a button to create a permanent link that is guaranteed to be persisted forever in the metadata database. To complement this feature, we could also consider adding a config flag that would make it possible to disable the persistent link sharing functionality for orgs that prefer to only offer automatically expiring links.


-- 
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