-
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
Fix visualization individual timeranges #17123
Conversation
💔 Build Failed |
💔 Build Failed |
Jenkins, test this - very weird test failure |
Vega portion seems reasonable, thx! |
💔 Build Failed |
💔 Build Failed |
💔 Build Failed |
💔 Build Failed |
Jenkins, test this (somehow the push didn't trigger a build) |
Jenkins, test this |
💔 Build Failed |
💔 Build Failed |
Jenkins, test this - just to make sure it's a consistent failure |
💔 Build Failed |
💔 Build Failed |
Jenkins, test this |
💚 Build Succeeded |
@@ -699,6 +699,10 @@ function discoverController( | |||
return $scope.vis.getAggConfig().toDsl(); | |||
}); | |||
} | |||
|
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.
Since the date histogram in the chart looks into this variable expected to be set by visualize.js
we need to set it explicitly in the places we use <visualization>
directly. This is currently only discover. I think in the long run with the new chart component in EUI we should rather use the chart component directly and not any part of the visualize stack anymore in Discover, since discover and visualize already have a ton of special handling just for this one chart.
@@ -71,6 +71,7 @@ | |||
app-state="state" | |||
editor-mode="chrome.getVisible()" | |||
show-spy-panel="chrome.getVisible()" | |||
time-range="timeRange" |
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.
Pass down the timeRange explicitly from the editor app.
@@ -8,25 +8,25 @@ const MetricsRequestHandlerProvider = function (Private, Notifier, config, timef | |||
|
|||
return { | |||
name: 'metrics', | |||
handler: function (vis, appState, uiState) { | |||
handler: function (vis, { uiState, timeRange }) { |
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.
Make TSVB request handler only use the passed timeRange and not looking into timefilter directly anymore.
@@ -12,28 +12,20 @@ const TimelionRequestHandlerProvider = function (Private, Notifier, $http, $root | |||
|
|||
return { | |||
name: 'timelion', | |||
handler: function (vis /*, appState, uiState, queryFilter*/) { | |||
handler: function (vis, { timeRange }) { |
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.
Make timelion request handler only use the explicitly passed timeRange
instead of accessing timefilter.time
directly.
@@ -13,7 +13,8 @@ export function VegaRequestHandlerProvider(Private, es, timefilter, serviceSetti | |||
|
|||
name: 'vega', | |||
|
|||
handler(vis) { | |||
handler(vis, { timeRange }) { | |||
timeCache.setTimeRange(timeRange); |
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.
Pass in the timeRange
that the vega request handler got into the timecache, that is used.
handler: function (vis, appState, uiState, queryFilter, searchSource) { | ||
handler: function (vis, { appState, queryFilter, searchSource, timeRange }) { | ||
|
||
searchSource.filter(() => { |
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.
Move applying the timeRange
filter on searchSource
into the actual courier request handler.
In the long run we want to remove searchSource
altogether from visualize, since this is courier request handler specific.
Everything else seems to be working well! btw reporting dashboard snapshots would have been great for this change. Probably would have caught the tilemap thing, too bad they are turned off! I'll get them back on at some point. |
@stacey-gammon I think that's actually a bug on master in the maps and not within this change. Whenever I try to change timeranges from a range that had data to a range that doesn't have data, the maps are just ignoring the new data and keep their state (because Could you please check if you can reproduce it on master, too with that information? In that case I would just open a separate ticket for that. Switching from one range with data to another with data seems to work fine for 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.
yup you're right, bug on master! lgtm
Opened #17327 for that issue. |
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.
to confirm: as for the remaining map-bug, I'm wrapping this up in a larger PR with another bug fix #17263.
* Fix visualization individual timeranges * Make Vega request handler use passed in timeRange * Remove unneeded private variable * Use timeRange for courier caching check * Fix developer documentation * Fix date_histogram * Fix issue * Fix broken tests * Fix issue in discover visualization * Fix vega tests * Fix issue with saved search visualizations * Update timeRange correctly in editor
* Fix visualization individual timeranges * Make Vega request handler use passed in timeRange * Remove unneeded private variable * Use timeRange for courier caching check * Fix developer documentation * Fix date_histogram * Fix issue * Fix broken tests * Fix issue in discover visualization * Fix vega tests * Fix issue with saved search visualizations * Update timeRange correctly in editor
💚 Build Succeeded |
Fixes #16823 and also touches the first parts of #16641
With this PR we make a step towards passing down all required information explicitly into the request handler instead of relying on searchSource inheritance or requiring the request handler to use
timefilter
directly to get the active bounds.This is needed for the long term plan, to get rid of the inheritance of
searchSource
altogether and always require all information to be specified in the loader. In the end the dashboard embeddable should also pass us the timerange in, this is currently blocked, since panels don't rerender when the timefilter changes. This will be fixed in a later point.This code still contains two TODOs, that will be needed to resolved at a later point.
timefilter.time
invisualize.js
as soon as the dashboard embeddables always pass us the time.API changes
This also changes the API of request handlers. A request handler, will now be passed in the following parameters:
requestHandler(vis, params)
, withparams
containing the following keys:appState
,uiState
,queryFilter
,searchSource
,timeRange
.Be aware, that
searchSource
andqueryFilter
will be removed in the future and instead the query and all filters will be passed as separate keys explicitly into the params.The
timeRange
should ALWAYS be used, and no request handler should be talking to thetimefilter
directly anymore. ThetimeRange
is an object containing at least afrom
andnow
key, which can be strings in the datemath syntax. To get timestamps either use thedatemath
library directly or usetimefilter.calculateBounds(timeRange)
instead.Note to QA
This PR changes the basic usage of time range in all visualizations. It has a high potential of breaking existing functionality, since this change affects every single visualization. If you find any errors, that could be related to the time range of the visualization not being used correctly, please feel free to suspect this PR and contact me immediately to help debugging it.
Update: I'am already marking that as a blocker (though this should all be done till feature freeze most likely anyway), since we would introduce a regression when using the vis loader, if this isn't merged, and specifying time ranges, wouldn't work anymore.