Bug description
Originally filed as https://github.com/apache/superset/issues/33105 but as a two-part issue which made it hard to track. We dealt with one part of the issue and closed that one. See that thread for some discussion about this sorting problem.
In Superset 4.0.2 you could sort both the x-axis and y-axis of the heatmap chart, allowing charts like this where day and hour are plotted against each other, both in logical order:
Starting in Superset 4.1 this doesn't work if some combinations lack data. The same chart in 4.1.2 has nonsensical y-axis ordering:
With the y-axis (day of week) in random order, the chart is less useful.
Screenshots/recordings
No response
Superset version
master / latest-dev
Python version
3.9
Node version
16
Browser
Chrome
Additional context
No response
Checklist
- [x] I have searched Superset docs and Slack and didn't find a solution to my problem.
- [x] I have searched the GitHub issue tracker and didn't find a similar bug report.
- [x] I have checked Superset's logs for errors and if I found a relevant Python stacktrace, I included it here as text in the "additional context" section.
Comment From: sfirke
Note from the other thread, this issue is looking for a community member to take it on.
Comment From: michael-s-molina
Heatmap lost ability to sort both y-axis and x-axis starting
@sfirke I believe the title does not correctly reflect the problem as you can sort by both but the order will vary depending on the available data.
As an additional context, the new Heatmap chart uses server-side ordering which is important given the limit restrictions that might be imposed by the query. The order controls are translated to ORDER BY clauses in the generated SQL. A proposed solution needs to account for this requirement.
Comment From: sfirke
Heatmap lost ability to sort both y-axis and x-axis starting
@michael-s-molina I have retitled the issue based on this feedback, let me know if you have improvements on the current title.
To understand better, it sounds like a proposed solution would need to respect the current ORDER BY clauses for the data retrieval query, and then adjust the result so that both axes are ordered consecutively. Is that right?
Comment From: michael-s-molina
To understand better, it sounds like a proposed solution would need to respect the current ORDER BY clauses for the data retrieval query, and then adjust the result so that both axes are ordered consecutively. Is that right?
Exactly! Thanks for adjusting the title.
Comment From: rusackas
I haven't validated the PR, but spin up a test env if you wanna try/review it :)