Skip to content
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

Preserve nested tables in table vis #24377

Merged
merged 11 commits into from
Oct 25, 2018
Merged

Conversation

lukeelmers
Copy link
Member

@lukeelmers lukeelmers commented Oct 22, 2018

Closes #24244

Summary

Resolves a regression introduced by the vis legacy response handler, where table vis was no longer able to display nested tables beyond one level deep when splitting on a table.

This led to two related regressions, both addressed here: date formatting in table titles was lost, and you could no longer use the "column" layout when splitting on a table.

After discussing with @ppisljar, we agreed the best way to approach would be to set up a table-specific response handler that knew how to handle the nesting, as the legacy response handler is now used in other vis types as well. As the new handler only serves a single purpose, it is not registered along with other response handlers; this should only be used with table vis.

Ultimately, this solution is only temporary until 7.0 when we can migrate table vis to handle splitting in a manner consistent with other vis types (i.e. one level of depth when splitting).

TODO: I'd like to add a few unit tests on this use case to avoid future regressions, will try to get those added tomorrow.

Checklist

Use strikethroughs to remove checklist items you don't feel are applicable to this PR.

For maintainers

return moment(parseInt(value)).format('YYYY-MM-DD');
}
return value;
}
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Someone must have written a util of some type to handle this elsewhere. I grepped around and was unable to find how we were previously formatting these dates in table titles, so added this naïve implementation for now. But I'd greatly appreciate if someone could point me in the right direction so that I can remove this!

const splitColumnIndex = columns.findIndex(column => column.id === splitColumn.id);
const rowsByColumnValue = keyRowsByValue(rows, splitColumn.id);
const filteredColumns = columns
.filter((column, i) => i !== splitColumnIndex)
Copy link
Member Author

@lukeelmers lukeelmers Oct 22, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In this column filter, I haven't included any of the isSplitMetric logic used in the legacy response handler because it did not appear to be necessary for the tables (I think?) -- but please correct me if I'm missing something.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i think this might not be the case ....
if we have metrics at all levels, the tabified table will look like: (for two nested term aggs, first one on os, second one on countr)

os  coiunt  country  count
win xp  230 CN  200
win xp 230 US 30
linux 120 CN 100
linux 120 CN 20

lets say os is the split column .... we should filter out that one + all the matching metrics (so all the metrics until the next bucket column)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@timroes and I were just testing and we think this isn't an issue based on our understanding (it seemed to behave consistently with both legacy and legacy_table handlers), but I will double check

@lukeelmers lukeelmers added blocker review regression v6.5.0 Team:Visualizations Visualization editors, elastic-charts and infrastructure bug Fixes for quality problems that affect the customer experience Feature:Data Table Data table visualization feature labels Oct 22, 2018
@elasticmachine
Copy link
Contributor

💚 Build Succeeded

Copy link
Member

@ppisljar ppisljar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i might be wrong about my comment, best to test it out ...

another thing that comes to mind is filters on other bucket ... you will need to preserve 'rawData' ..
so a reference to tabify table, the row and column .... take a look at vis/vis.js vis.API.filter method.

src/ui/public/vis/response_handlers/legacy_table.js Outdated Show resolved Hide resolved
const splitColumnIndex = columns.findIndex(column => column.id === splitColumn.id);
const rowsByColumnValue = keyRowsByValue(rows, splitColumn.id);
const filteredColumns = columns
.filter((column, i) => i !== splitColumnIndex)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i think this might not be the case ....
if we have metrics at all levels, the tabified table will look like: (for two nested term aggs, first one on os, second one on countr)

os  coiunt  country  count
win xp  230 CN  200
win xp 230 US 30
linux 120 CN 100
linux 120 CN 20

lets say os is the split column .... we should filter out that one + all the matching metrics (so all the metrics until the next bucket column)

@lukeelmers lukeelmers self-assigned this Oct 23, 2018
@lukeelmers lukeelmers removed the review label Oct 23, 2018
@elasticmachine
Copy link
Contributor

💚 Build Succeeded

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

@ppisljar
Copy link
Member

tested it out, as expected doens't work correctly with metricsAtAllLevels and doesn't apply the other bucket filters correctly.

@timroes
Copy link
Contributor

timroes commented Oct 24, 2018

@ppisljar Other bucket not working is not related to this PR at all, and wasn't working beforehand either. Could you please be more specific about metricsAtAllLevels is not working? Which steps/configuration did you use and what is the expected outcome?

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

The new legacy response handler introduced a regression in how nested
tables were handled within table vis. This adds a new table-specific
response handler to ensure splitting is preserved.

This is a short term solution and will be removed once we are able to
update table splitting to be consistent with other vis types.
@lukeelmers
Copy link
Member Author

@ppisljar @timroes split buckets are now correctly hidden with metricsAtAllLevels. i also rebased on latest master which includes a functional test Tim wrote for this exact use case.

Functional tests passed locally so hopefully that means a green build is on its way 🤞

@elasticmachine
Copy link
Contributor

💔 Build Failed

@lukeelmers
Copy link
Member Author

retest

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

@timroes timroes added the v7.0.0 label Oct 25, 2018
Copy link
Contributor

@timroes timroes left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tested, added tests and looks good to me.

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

@timroes timroes merged commit 40c232b into elastic:master Oct 25, 2018
timroes pushed a commit to timroes/kibana that referenced this pull request Oct 25, 2018
* Add legacy response handler for table vis.

The new legacy response handler introduced a regression in how nested
tables were handled within table vis. This adds a new table-specific
response handler to ensure splitting is preserved.

This is a short term solution and will be removed once we are able to
update table splitting to be consistent with other vis types.

* Ensure formatted dates are preserved in table titles.

* Update legacy table response handler based on feedback.

* Ensure AggConfigResult.rawData is preserved in legacy table response handler.

* Move legacy table response handler to core_plugins.

* Legacy table response handler - style cleanup.

* Remove unneeded aggConfigResult.rawData from legacy table response handler.

* Add basic unit tests for legacy table response handler.

* In table vis, exclude split columns when showing metrics at all levels.

* Add functional tests
timroes added a commit that referenced this pull request Oct 25, 2018
* Add legacy response handler for table vis.

The new legacy response handler introduced a regression in how nested
tables were handled within table vis. This adds a new table-specific
response handler to ensure splitting is preserved.

This is a short term solution and will be removed once we are able to
update table splitting to be consistent with other vis types.

* Ensure formatted dates are preserved in table titles.

* Update legacy table response handler based on feedback.

* Ensure AggConfigResult.rawData is preserved in legacy table response handler.

* Move legacy table response handler to core_plugins.

* Legacy table response handler - style cleanup.

* Remove unneeded aggConfigResult.rawData from legacy table response handler.

* Add basic unit tests for legacy table response handler.

* In table vis, exclude split columns when showing metrics at all levels.

* Add functional tests
@lukeelmers lukeelmers deleted the fix/table-nesting branch October 25, 2018 14:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
blocker bug Fixes for quality problems that affect the customer experience Feature:Data Table Data table visualization feature regression Team:Visualizations Visualization editors, elastic-charts and infrastructure v6.5.0 v7.0.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants