-
Notifications
You must be signed in to change notification settings - Fork 8.2k
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
Visualization specific timeranges #15998
Conversation
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.
Looks great. How about some search source tests that filter out some filters
Good point, I'll add some unit tests for the |
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.
nice! LGTM
* No longer converting the $scope.timeRange to absolute values in visualize.js * Now using searchSource.filter as opposed to manual approach * Adding extensible filters and only including the first timeRange filter * Removing the forceNow stuff, we'll deal with this in another PR * Adding omment about removing null/undefined filters * Adding vis.getTimeRange and using it in the Date Histogram * Removing the test hard-coded timeRange * Adding tests for default filter "filters" * Adding custom filter prediate test
* No longer converting the $scope.timeRange to absolute values in visualize.js * Now using searchSource.filter as opposed to manual approach * Adding extensible filters and only including the first timeRange filter * Removing the forceNow stuff, we'll deal with this in another PR * Adding omment about removing null/undefined filters * Adding vis.getTimeRange and using it in the Date Histogram * Removing the test hard-coded timeRange * Adding tests for default filter "filters" * Adding custom filter prediate test
The previous approach to visualization specific timeranges had a few deficiencies:
This PR changes the approach, and we're no longer breaking the SearchSource inheritance. Instead, I've made the "filter filtering" a first class citizen of the SearchSource and added an extension point so that specific SearchSource instances are able to reject certain filters. This allows us to ensure that only one range filter is added to the SearchSource, and ignore the global time filter that was being added.
Additionally, we're no longer calculating the absolute min/max times from the timeRange when first "linking" the Visualization so that these values are able to change over time. The way that we're passing the custom timeRange to the DateHistogramAggregation has been revised as well to alleviate the same limitation of the values changing over time.