nytai commented on pull request #18181:
URL: https://github.com/apache/superset/pull/18181#issuecomment-1041955168


   I think redis is a natural choice in the context of preset where there is 
already a very heavy reliance on redis for critical business logic. I'm not 
convinced all superset deployments would lead to the same conclusion. A lot of 
superset community members are running the `latest` docker tag (whether 
intending to run bleeding edge or not) and have already started to experience 
some of the effects of this change, eg 
https://apache-superset.slack.com/archives/C0170U650CQ/p1644941586344789. 
   
   While adding a default cache config that write to a db table seems like a 
more ideal option, I understand the reluctance to go that route especially 
since it will be overridden in preset with a redis cache anyway. I think we 
should at the very least add some more comments around what type of setup is 
recommended for single/multi instance deployments. Additionally, issuing a 
warning in logs (with some way of ack/disabling it) if the default filecache is 
being used seems like it could go a long way in preventing some of the upgrade 
pains that users are likely to experience in the upcoming release. 
   
   @villebro regarding this problem getting worse in recent version, I think 
it's due to the native filters data structure having a larger footprint than 
filterbox. The biggest culprit that I have found so far is the dashboard color 
scheme override, this ends up really blowing up the json payload. I have been 
telling users to exercise caution with that feature and expect "view chart in 
explore" to break if a dashboard color scheme is applied. 


-- 
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: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]



---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to