-
Notifications
You must be signed in to change notification settings - Fork 13.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chore(explore): Migrate BigNumber to v1 api [ID-28][ID-55] #17587
Conversation
Codecov Report
@@ Coverage Diff @@
## master #17587 +/- ##
=======================================
Coverage 67.72% 67.72%
=======================================
Files 1602 1602
Lines 64146 64154 +8
Branches 6773 6773
=======================================
+ Hits 43442 43450 +8
Misses 18851 18851
Partials 1853 1853
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
/testenv up |
@kgabryje Ephemeral environment spinning up at http://54.218.60.103:8080. Credentials are |
14f2ffb
to
36bdfbc
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One last nit, other than that LGTM and works and looks really great!
from_dttm: number | null; | ||
to_dttm: number | null; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It appears the ChartDataResponseResult
schema is pretty badly out of sync with this. For example, the following appear to be missing or have an incorrect name:
- here we have
cache_dttm
, onChartDataResponseResult
we havecached_dttm
colnames
andcoltypes
are missing onChartDataResponseResult
.from_dttm
andto_dttm
should also be added toChartDataResponseResult
.
Let's try to make sure these are in sync.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM but I think we may need a db migration script
}, | ||
}, | ||
], | ||
[ | ||
{ | ||
name: 'header_timestamp_format', | ||
name: 'force_timestamp_formatting', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are we renaming existing config props in use? Might need a db migration script if that's the case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point, done
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM - tested to be compatible with the old metadata in all cases that I was able to come up with.
c994d96
to
9267afc
Compare
superset/migrations/versions/fe23025b9441_rename_big_viz_total_form_data_fields.py
Outdated
Show resolved
Hide resolved
superset/migrations/versions/fe23025b9441_rename_big_viz_total_form_data_fields.py
Outdated
Show resolved
Hide resolved
header_format_selector = params.pop("header_format_selector", None) | ||
header_timestamp_format = params.pop("header_timestamp_format", None) | ||
if header_format_selector: | ||
params["time_format"] = header_format_selector | ||
if header_timestamp_format: | ||
params["force_timestamp_formatting"] = header_timestamp_format |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think these are inverted - shouldn't header_format_selector
be migrated to force_timestamp_formatting
and header_timestamp_format
to time_format
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for spotting that!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM - Retested with migrations and before and after look the same now with forced timestamp on BigNumberTotal
.
except Exception as e: | ||
print(e) | ||
print(f"Parsing params for slice {slc.id} failed.") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've seen a couple migrations that succeeded even when exceptions were raised, and they always had to be fixed later to address inconsistent states.
Here, it would be better to raise the exception, so that the migration fails and the admin has the chance to fix the offending charts before trying again. Otherwise, if the migration succeeds they might not even see the message, leaving their system inconsistent, and even if they see the message they need to downgrade and upgrade, which is more work.
Also, can you update your summary confirming that migrations are atomic, have been tested, and share the benchmark numbers? You can use scripts/benchmark_migration.py
to get the numbers.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the comment! I updated the description and and re-raised the exception
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thanks for fixing the migration!
superset/migrations/versions/fe23025b9441_rename_big_viz_total_form_data_fields.py
Show resolved
Hide resolved
❗ Please consider rebasing your branch to avoid db migration conflicts. |
1 similar comment
❗ Please consider rebasing your branch to avoid db migration conflicts. |
8a10fd0
to
944ae17
Compare
Ephemeral environment shutdown and build artifacts deleted. |
Hello! I am pretty sure this is currently breaking Charts and Dashboards for me. When I try to open a dashboard I get: It fails here: https://github.com/apache/superset/blob/master/superset-frontend/src/visualizations/presets/MainPreset.js#L98 When I comment this out it continues working, but obviously then there are no Big Numbers. |
) * chore(explore): Migrate BigNumber to v1 api * Move to echarts * Use Echarts trendline * Fix imports * Fix parsing dates as strings * Add from_dttm and to_dttm to v1 chart response * Fix post processing * Fix timeRangeFixed * Fix tests * Remove from and to dttm from cache * Cleanup date formatting * Fix storybook * Fix missing types * Fix timestamp with timezone * Add types to demo's tsconfig * bug fix * fix import * Fix cypress tests * add sort * add resample to handle missing values properly * Sync ChartDataResponseResult schema with ts interface * Lint fix * Add migration * Fix migration * Remove pass * Re-raise the exception in migration * Typo fix * Update revision Co-authored-by: Ville Brofeldt <ville.v.brofeldt@gmail.com>
) * chore(explore): Migrate BigNumber to v1 api * Move to echarts * Use Echarts trendline * Fix imports * Fix parsing dates as strings * Add from_dttm and to_dttm to v1 chart response * Fix post processing * Fix timeRangeFixed * Fix tests * Remove from and to dttm from cache * Cleanup date formatting * Fix storybook * Fix missing types * Fix timestamp with timezone * Add types to demo's tsconfig * bug fix * fix import * Fix cypress tests * add sort * add resample to handle missing values properly * Sync ChartDataResponseResult schema with ts interface * Lint fix * Add migration * Fix migration * Remove pass * Re-raise the exception in migration * Typo fix * Update revision Co-authored-by: Ville Brofeldt <ville.v.brofeldt@gmail.com>
SUMMARY
This PR's goal is to make the legacy Big Number chart plugin not-so-legacy-anymore.
First improvement is migrating the chart endpoint from legacy to V1 API. This change will also allow proper handling of timestamp format metrics. The legacy API assumed that metric result is always a number - if you used a metric that should return a datetime (e.g.
MAX(temporal_column)
) with a db that returns dates as strings (like sqlite or druid), you'd get nulls in response (see screenshots).Second thing - to render the trendline, we used
@data-ui/xy-chart
library, which hasn't been maintained for 2 years. I replaced it with Echarts, which is our go-to viz library.Lastly, the legacy plugin wasn't able to handle rolling aggregates properly if values were missing. The new version ensures that rolling windows are resampled with null values when a time grain is used to ensure that the calculation window always has the correct number of lagged values applied.
DB migration benchmark results:
BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF
Before:
After:
TESTING INSTRUCTIONS
Big Number and Big Number with Trendline core functionalities should work like before.
Timestamp metrics should be formatted automatically.
Steps to reproduce bug shown on screenshots:
MAX(temporal_column)
)ADDITIONAL INFORMATION
CC @junlincc @jinghua-qa