-
Notifications
You must be signed in to change notification settings - Fork 892
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
[BUG] Add Data table bucket Split rows agg limit of 3 #1179
[BUG] Add Data table bucket Split rows agg limit of 3 #1179
Conversation
Hello @RoyiSitbon, Thanks for opening this. Will check it out, right now it's blocked because the tests are failing due to this issue. Initial nitpick feedback would be if you can some of the content you added to the PR to the commit description that provide insight on the commit without having to come to the PR. Also, I believe this could potential to add a quick test to verify it limits to 3. |
Hey, sure. Thanks for the feedback. |
I often want to split on more than 3 fields and losing this ability would be a step backwards when data sets are small and performance is not an issue. Is there any scope of making this configurable setting with a default of 3? |
The functionality of allowing more than 3 splits in data tables has been present since Kibana 4 and I use this ability regularly. Sadly I have many visualisations that would break and just not be possible unless it were possible to configure this limit. |
I see there is probably historical reason to have this not be capped at 3. Perhaps, @ahopp or @kgcreative, what do y'all think about this change? Does it seems like a good improvement to make all of them similar in behavior and have an override config? Or can we gather more insight on the potential impact? |
@kavilla, @RoyiSitbon, @jgough - I would prefer to handle this in a way where we don't introduce a breaking change. I would suggest a configuration option that's empty by default to introduce a split field limit (either in stack management, or kibana yml, or somewhere else). This would allow admins to configure this limit if needed for performance reasons, but wouldn't break existing functionality. This setting should then be enforced by any visualization that uses split fields in agg buckets. maybe something like For additional corner case handling, existing visualizations with split fields beyond N would only display N split rows. |
Sure, that sounds good to me. Thanks |
Hey, I changed it to be a configurable solution as talked. |
Hi @RoyiSitbon, if you rebase the tests should pass (granted if no failures by new implementation). Would you like for me to rebase for you on your branch? Let me know. Thank you! Also, would there be an ability to add some tests to test this new functionality. |
f75cdfa
to
b797497
Compare
Hey, rebased |
Added a new functional test with the right flow as well. |
c3a8a60
to
734ccea
Compare
Signed-off-by: sitbubu <royi.sitbon@logz.io>
Signed-off-by: sitbubu <royi.sitbon@logz.io>
Signed-off-by: sitbubu <royi.sitbon@logz.io>
Signed-off-by: sitbubu <royi.sitbon@logz.io>
734ccea
to
7fc8d18
Compare
Signed-off-by: sitbubu <royi.sitbon@logz.io>
Sorry. I commented on the wrong place: #1178 (comment) I will re-check it. |
Hey @RoyiSitbon After the latest change, advanced settings does not set a default split limit which is great. I have verified that. But I think the function is still not working right? For example, I set the advanced settings with/without max to limit the split to 3: Then go to visualization, create a data table using eCommerce sample data. However, I could still split even I have 3 buckets. First, the "Split rows" option has no changes and still clickable. Second, adding one more split is still working. We could see a descending based on product quality. So I am bit confused here. Did I mis-use or mis-understand here? pls help |
My bad. It turns a cache issue and need to refresh the page to reload the settings. It is better to use |
Meanwhile, I have several questions
Probably we should discuss more here. |
Hey, |
I think it would be worth documenting all of the different visualizations that can use bucket aggregations. I think one question for the community here is if we want to have to pass all the different visualization types in order to change the split limit on all of them, or if there is an approach that can cover all visualization types, and, if desired, control individual visualizations at a more granular level. From reading the issue, this seems to come from a desire to limit potentially expensive queries on large data sets, so it feels like a single setting to control the split limit everywhere it's used would be friendlier than having to control these individually |
Hey @kgcreative, thanks for replying. Thanks |
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.
Based on #1178 this does not seem to address the real problem here. If the goal is to limit expensive aggregations dynamically, this only does that for the table agg and that too for the Split Row
agg type. I believe that issue needs a lil more discussion before we implement a solution. I'll call out my concerns and possible solutions in that issue.
@@ -45,6 +45,10 @@ export function getTableVisTypeDefinition( | |||
core: CoreSetup, | |||
context: PluginInitializerContext | |||
): BaseVisTypeOptions { | |||
const tableBucketAggAmounts = core.uiSettings.get('visualize:aggAmounts')?.table?.bucket; |
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'm a lil confused by this change. This UI setting only applies to the table viz since its used in the table_vis_type
. But the setting is labeled as a way to dynamically set the min and max agg limits for the bucket viz. That is not the case. Am i missing something?
[VISUALIZE_AGG_AMOUNTS]: { | ||
// currently only supports dataTable vis | ||
name: i18n.translate('visualizations.advancedSettings.visualizeAggAmountsTitle', { | ||
defaultMessage: `Set bucket's aggregation min, max level limitation`, |
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.
Any reason to only limit the bucket agg and not the metric agg too?
@RoyiSitbon I'm going to convert this to a draft until we can come to consensus on a more general approach as discussed in #1178. |
We are closing this PR because what it says and does is very different. Next steps to resolve the discussion on #1178. After that feel free to open a new PR. |
Signed-off-by: sitbubu royi.sitbon@logz.io
Description
The default limit of 3 “Split rows” aggregated buckets isn't applied on this visualization which allows adding more buckets and can harm cluster performance.
In other types of visualizations, there is a default limit of up to 3 “Split rows” aggregated buckets, e.g. Horizontal-Bar visualizations.
We wish to have an option to configure the max,min limitation for the “Split rows” aggregated bucket under dataTable vis.
i.e. Using this configuration, we will limit the max amount to 3:
This way we will see the next result in our UI:
If we won't set any limitation, i.e:
We will have same behavior as now:
linked issue:
#1178