fix(cache): Add cache warmup for non-legacy charts#24671
Conversation
Codecov Report
@@ Coverage Diff @@
## master #24671 +/- ##
=======================================
Coverage 68.89% 68.89%
=======================================
Files 1901 1901
Lines 73927 73925 -2
Branches 8183 8183
=======================================
- Hits 50932 50931 -1
+ Misses 20874 20873 -1
Partials 2121 2121
Flags with carried forward coverage won't be shown. Click here to find out more.
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
There was a problem hiding this comment.
This logic (for the most part) has just been indented.
There was a problem hiding this comment.
Adhering to the DRY principle.
There was a problem hiding this comment.
I have no idea why this was here.
There was a problem hiding this comment.
Ensure we can successfully warm up legacy and non-legacy charts.
There was a problem hiding this comment.
I have no idea why this was here.
There was a problem hiding this comment.
The load_energy_table_with_slice fixture is not required.
a097d67 to
aa07137
Compare
aa07137 to
05904e6
Compare
There was a problem hiding this comment.
Raising a ChartInvalidError seems more appropriate than raising an Exception.
There was a problem hiding this comment.
@michael-s-molina I gather it's now too late to remove this endpoint in 3.0 given there's a new target.
There was a problem hiding this comment.
Let's remove it in 4.0 given that the breaking window is closed.
05904e6 to
abfb6c1
Compare
michael-s-molina
left a comment
There was a problem hiding this comment.
Thank you for the PR @john-bodley. I left some first-pass comments.
There was a problem hiding this comment.
Why did you add the query_context to the payload of exported charts?
There was a problem hiding this comment.
@michael-s-molina this logic was extracted from #23012.
There was a problem hiding this comment.
The problem with this approach is that we have non-legacy charts that are also present in viz_types under the same key like table and big_number.
There was a problem hiding this comment.
@michael-s-molina that may explain why testing with the table viz type was problematic.
Should the table, big_number, etc. viz types be removed from superset.viz? Alternatively if they’re still required, i.e., we simultaneously support both legacy and non-legacy versions, how does Superset differentiate between the two? Is it the presence of the query context?
There was a problem hiding this comment.
Should the table, big_number, etc. viz types be removed from superset.viz?
Yes. Let's remove them.
There was a problem hiding this comment.
See #24694 which is now a precursor to this PR.
e90379d to
aaefe70
Compare
aaefe70 to
74f25f0
Compare
|
@michael-s-molina this PR is now ready for re-review. |
| break | ||
| except Exception as ex: # pylint: disable=broad-except | ||
| error = error_msg_from_exception(ex) | ||
| status = None |
There was a problem hiding this comment.
Do we have a status for errors?
There was a problem hiding this comment.
It seems not. This is the same logic as previously.
michael-s-molina
left a comment
There was a problem hiding this comment.
LGTM. I left a non-blocking comment about the status when there's an error.
|
@john-bodley Thank you so much. This one is very helpful! |
(cherry picked from commit 5f49e0f)
|
Hi @john-bodley, we have found something funny. We noticed that some charts have been cached by cache warmup job, which is good. But if we click the dashboard, it seems those charts in the dashboard are not using the warmup cache. Do you have any idea? Thank you. |
|
Hi @stepcheunghk , Are there any native filters or other filters applied to the chart as part of dashboard? |
|
Hi @dheeraj281 , you are right. Definitely there are some filters applied to the chart/ dashboard. What should I do now? Thanks man. |
|
@stepcheunghk Yes, thats the reason.. It refreshes the chart objects related to the dashboard. When native filter is applied on the dashboard, its a different query now. If you dont keep any filter with default value, it should work as expected. |
|
@dheeraj281 I see. Thanks for your prompt reply and clear explanation. 🙂 |
|
Hi @dheeraj281 @stepcheunghk |
|
Hi @oriabyi I am not aware of any such functionality right now. As discussed above It refreshes the chart objects related to the dashboard. it basically loads the chart url with force=true. One way of refreshing dashboard could be a separate selenium script that loads the dashboard url with url param "force=true" Even we had this requirement of refreshing a dashboard with a native filter with a default value and also in it. To handle that in superset for our internal use, I have changed the cache-refresh functionality to work from the backend instead of using selenium and chart url approach. In backend it will identify charts and all the associated dashboard level filters of it and runs the exact same query which is their at dashboard level using chartDataCommand. If many users wants this, I can create a PR for the same. |
|
@dheeraj281, thank you, it helped a lot, truly appreciate it. |
SUMMARY
This PR is a rehash of #23012 which was later reverted by #23579 in combination with #23569.
The logic defined here is the inverse of #23012, i.e., rather than trying to identify if a chart is a non-legacy chart (via the presence of the query-context—which was problematic), instead we check if the chart is a supported legacy chart/viz type.
BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF
TESTING INSTRUCTIONS
Added unit tests.
ADDITIONAL INFORMATION
cc: @alexryndin @dheeraj-jaiswal-lowes