fix: time comparision

[zhaoyongjie]

SUMMARY

fix time comparison, follow the viz.py pattern

difference: original column - compared column
percentage: (original column - compared column) / compared column
radio: original column / compared column

BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

TESTING INSTRUCTIONS

ADDITIONAL INFORMATION

• Has associated issue:
• Required feature flags:
• Changes UI
• Includes DB Migration (follow approval process in SIP-59)
  • Migration is atomic, supports rollback & is backwards-compatible
  • Confirm DB migration upgrade and downgrade tested
  • Runtime estimates and downtime expectations provided
• Introduces new feature or API
• Removes existing feature or API

[codecov]

Codecov Report

Merging #19659 (b0b5e9c) into master (5c63df5) will decrease coverage by 0.10%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master   #19659      +/-   ##
==========================================
- Coverage   66.47%   66.37%   -0.11%     
==========================================
  Files        1681     1681              
  Lines       64468    64468              
  Branches     6607     6607              
==========================================
- Hits        42857    42788      -69     
- Misses      19917    19986      +69     
  Partials     1694     1694              

Flag	Coverage Δ
hive	?
mysql	81.90% <100.00%> (ø)
postgres	81.95% <100.00%> (ø)
presto	52.51% <0.00%> (ø)
python	82.17% <100.00%> (-0.22%)	⬇️
sqlite	81.72% <100.00%> (ø)
unit	47.71% <100.00%> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
superset/utils/pandas_postprocessing/compare.py	90.32% <100.00%> (ø)
superset/db_engines/hive.py	0.00% <0.00%> (-85.19%)	⬇️
superset/db_engine_specs/hive.py	70.11% <0.00%> (-15.71%)	⬇️
superset/db_engine_specs/base.py	88.01% <0.00%> (-0.34%)	⬇️
superset/connectors/sqla/models.py	89.27% <0.00%> (-0.19%)	⬇️
superset/utils/core.py	89.71% <0.00%> (-0.12%)	⬇️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 5c63df5...b0b5e9c. Read the comment docs.

[villebro]

Tested to work as expected when comparing legacy line chart to v2 line chart. Only one unrelated problem observed when testing with GENERIC_CHART_AXES set to true on SQLite (the temporal axis is string based, causing the time diff to fail). But this is not a blocker.

[john-bodley]

@villebro @zhaoyongjie this fixes a fairly major regression (#19116) in my opinion, i.e., we have users reporting incorrect results which triggers a SEV-0 at Airbnb given that the most egregious error for a BI tool is actually reporting misinformation which is far worse than no information and/or an error.

I was wondering whether Preset et al. were planning to do a post mortem (or similar) for this? The topic of post mortems might be a good topic to raise during the Superset Operational Model—Quality track.

[zhaoyongjie]

@john-bodley, sorry for introducing the regression, I will do a more comprehensive integration test of the query object and advanced analysis.

[john-bodley]

@zhaoyongjie out of interest were there no unit tests previously for testing the time comparisons?

[zhaoyongjie]

@john-bodley there was unit test for time comparisons, but the query results depended on combination of multiple operators and QueryObject. Unfortunately, there wasn't it. I will add these recently.

[villebro]

villebro zhaoyongjie this fixes a fairly major regression (#19116) in my opinion, i.e., we have users reporting incorrect results which triggers a SEV-0 at Airbnb given that the most egregious error for a BI tool is actually reporting misinformation which is far worse than no information and/or an error.

I was wondering whether Preset et al. were planning to do a post mortem (or similar) for this? The topic of post mortems might be a good topic to raise during the Superset Operational Model—Quality track.

@john-bodley it would be great to get guidelines for what types of regressions require more formal post mortems. If we had these types of guidelines in place, it would be easy to take that into consideration during code review. For instance, anything that affects calculation logic requires sign off from more committers or similar.

Also, @zhaoyongjie raised a good point about the previous tests not being specific enough. I think if we strive to make as isolated tests as possible that test for "obvious" cases (in this case that a change is +100, not -100, and that a going from 100 to 200 is +100 % and not, say, +50 % due to using an incorrect denominator in the calculation), the risk for these types of flipped sign regressions would not occur as easily. I'm happy to jump on a call to discuss this or assist in formalizing guidelines for this so we avoid similar problems going forward.