Open wylieconlon opened 4 years ago
Pinging @elastic/kibana-app (Team:KibanaApp)
geo.src
is already used in the table, the generated table will usually be reductive instead of additive. Users don't expect reductive suggestions here.Another improvement (which is more performance related): Dragging new string fields into the workspace will add them as top value dimensions. This will get relatively expensive for a lot of fields as nested terms aggregations have to be created.
In a lot of cases the user only wants to show a value from the document and it will always be the same one for all documents (like a partially aggregated doc table). These large nested term aggregation are quickly becoming expensive.
My suggestion:
@flash1293 that sounds good, and this is a very common pattern when constructing data tables. We can give these suggestions a relatively high score because the Table is the only visualization that allows buckets + strings as metrics.
I don't think we need a new dimension group for this, I'm not sure what benefit it gives us.
The dimension group would nudge users to not drop string fields into the "rows" group - it's a little weird "last value" is a "metric" in this case. But we can also start without this.
When a user drops a field into the Lens table, the results are unexpected. The main reason is that the table suggestions are built with the same logic as bar/line suggestions, and then limited. Tables need their own suggestion logic.
Examples of unexpected behavior:
geo.src
is already used in the table, the generated table will usually be reductive instead of additive. Users don't expect reductive suggestions here.Solving these problems is likely dependent on cleaning up suggestion logic and solving some of the architectural issues with how datasources and visualizations work together.