nytai edited a comment 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 adding 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, or are already experiencing due to running `latest`. @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. However, 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: notifications-unsubscr...@superset.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: notifications-unsubscr...@superset.apache.org For additional commands, e-mail: notifications-h...@superset.apache.org
