-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
Remove nested table splits from table vis #26057
Remove nested table splits from table vis #26057
Conversation
Pinging @elastic/kibana-app |
This comment has been minimized.
This comment has been minimized.
9f15bb8
to
7d4ba44
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
3ff4856
to
5cfe5cc
Compare
This comment has been minimized.
This comment has been minimized.
This makes the behavior of table vis consistent with other vis types.
This migration modifies any table visualizations that have more than one split agg ("nested tables") to ensure they only have a maximum of 1 split. Other aggs are converted to bucket aggs.
5cfe5cc
to
f01f3ac
Compare
This comment has been minimized.
This comment has been minimized.
💚 Build Succeeded |
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 almost gave this an LGTM w/ tweaks, because I like it. Good commenting throughout, and code that is easy to read. But it seems like there are some changes that probably need to be made, particularly around failed migrations.
src/legacy/core_plugins/kibana/public/visualize/editor/lib/migrate_app_state.js
Outdated
Show resolved
Hide resolved
This comment has been minimized.
This comment has been minimized.
💚 Build Succeeded |
After discussion with @chrisdavies and @timroes, we decided to intentionally throw an error if something goes wrong during the migration. We determined there are pros and cons to both approaches (failing silently vs failing fast). On the one hand, this migration is primarily for data consistency, as a vis will still render as expected (with nesting deprecated) regardless of whether the migration is successfully applied. However, we felt the most likely cause of a migration failure for this specific instance would be a malformed I've pushed an update with this change; here is an example of the error output you would receive during a failed migration (note that the migrations process already logs a warning, but then we throw an error with a stack trace to the specific migration): |
💚 Build Succeeded |
* | ||
* @param appState {AppState} AppState class to instantiate | ||
*/ | ||
export function migrateAppState(appState) { |
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 would be nice if there was a registry so plugins that create visualizations can migrate their app state as well.
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.
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.
Oh wait, you're talking about appState
-- I misread. That's a good idea, we have only used this one other place (dashboards), but it's good to hear this is something you feel would be useful to expose to plugins too!
Perhaps we could implement a solution that mimics whatever resolution we come to for #29122.
💚 Build Succeeded |
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. I didn't pull down or test, just mainly looked over the migrations side of it, which seems reasonable to me.
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 we can still delete the legacy_response_handler
file for the table vis, it shouldn't be used anymore? Otherwise that LGTM. I tried creating a table vis with nested splits on master and than switched to the PR. Looks like the migration and the app state migrations are working properly.
💚 Build Succeeded |
@lukeelmers Could you please add the description of this issue to the breaking changes doc? |
Closes #24560
In preparation for #16639
This restricts the data table vis to only allow one split bucket agg, making tables consistent with other vis types in Kibana. There are a number of reasons that making this change desirable, perhaps most notably that we no longer need to maintain a bunch of custom code for one specific vis type (for example, the table vis uses its own response handler rather than the response handler shared by other vis types).
A saved object migration is included so that existing saved visualizations won't be broken. Rather, they'll be converted so that any non first level split table bucket becomes a split row bucket. This update qualifies as a breaking change because it will change the structure & look of a table vis for any users who are using visualizations with nested tables.
QA
To test the migration, I've been using the following steps:
kibana_sample_data_logs
& note the vis ID in the URL... you will need this later.Mangement > Saved Objects
and find the vis you just saved.visState
box with the following & hit "Save":Management > Saved Objects
and note that thevisState
has been changed to only contain one agg withschema: "split"
.migrationVersion
back to anything pre-7.0:Remaining tasks
Checklist
- [ ] This was checked for cross-browser compatibility, including a check against IE11- [ ] Any text added follows EUI's writing guidelines, uses sentence case text and includes i18n support- [ ] This was checked for keyboard-only and screenreader accessibility- [ ] Documentation was added for features that require explanation or tutorialsFor maintainers
Release notes
release-note: Removes nested table splits from data table visualizations.
Previously a user was able to create multiple "split table" aggregations in one table on arbitrary levels. This required nesting tables within table cells, within other table cells. The potential for deeply nested tables posed maintenance and accessibility challenges, and was inconsistent with other visualizations which only allow one table split.
This change does not limit the number of split rows a user can put into a table; it only restricts the number of split tables to 1.
To prevent breaking existing visualizations, saved objects containing nested table splits have been migrated to contain only one split table, converting any existing split tables beyond the first to split rows. This preserves all existing visualizations, but will cause data table visualizations with multiple split tables to display differently than they had previously.