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

Add dateHistogramInterval utility #39091

Merged
merged 7 commits into from
Jun 25, 2019

Conversation

timroes
Copy link
Contributor

@timroes timroes commented Jun 17, 2019

Summary

Adds the dateHistogramInterval utility, which can be used to calculate the correct interval key (calendar_interval or fixed_interval) for a given interval string (like 10s, 1h, etc.).

The return will be an object that can simply spreaded into a date_histogram body. So you should replace your previous interval key by a call to that function:

// You can also use an relative import to the path `src/legacy/core_plugins/data/common` instead
+ import { dateHistogramInterval } from 'plugins/data/common';

const aggregation = {
  date_histogram: {
    field: '@timestamp',
-   interval: '10s',
+   ...dateHistogramInterval('10s'),
  },
};

This function will throw an error if the interval itself is not a valid Elasticsearch interval (like 2w, 5.0h, ...). Please make sure if you use it for user input, that the user input is properly validated beforehand and you show the user a meaningful error message. You can use the isValidEsInterval function as follows:

import { isValidEsInterval } from 'plugins/data/common';

const isValid: boolean = isValidEsInterval('10s');

Release Summary: Migrate date_histograms to the new calendar_interval/fixed_interval. Solves some deprecation warnings in Kibana.

For reviewers

This PR adds a bit of tech-debt, since we import directly from the plugins/data/common folder (which is not one of the root folders we should import later on). Unfortunately there are still a couple of unsolved issues around testing and NP plugins, why we decided to for now introduce that tech-debt, especially since it's really easy to change those imports later on.

This PR also makes use of this method in courier via AggConfig and also makes sure the editor properly validates that value beforehand.

There are a lot of test fixes, now that the AggConfig actually needs a valid interval since it would otherwise throw an exception.

Checklist

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

For maintainers

@timroes timroes mentioned this pull request Jun 17, 2019
7 tasks
@elasticmachine
Copy link
Contributor

💔 Build Failed

@timroes
Copy link
Contributor Author

timroes commented Jun 17, 2019

Jenkins, test this - short CI outage

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

@timroes timroes added Feature:Aggregations Aggregation infrastructure (AggConfig, esaggs, ...) Team:AppArch Team:Visualizations Visualization editors, elastic-charts and infrastructure labels Jun 17, 2019
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-app

@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-app-arch

@timroes timroes requested review from flash1293 and removed request for mattkime and lizozom June 17, 2019 19:20
@timroes timroes marked this pull request as ready for review June 17, 2019 19:24
@timroes timroes requested a review from a team as a code owner June 17, 2019 19:24
@timroes timroes requested a review from Bargs June 17, 2019 19:31
@timroes timroes requested a review from lukeelmers June 18, 2019 11:31
@markov00
Copy link
Member

cc @emmacunningham FYI (replacement of discover chart)

Copy link
Contributor

@flash1293 flash1293 left a comment

Choose a reason for hiding this comment

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

Code LGTM. Is there a specific reason to re-export this under static and common? Will this be a convention in NP?

@@ -53,7 +53,7 @@ export default {
'!src/legacy/core_plugins/**/__snapshots__/**/*',
],
moduleNameMapper: {
'^plugins/([^\/.]*)/(.*)': '<rootDir>/src/legacy/core_plugins/$1/public/$2',
'^plugins/([^\/.]*)(.*)': '<rootDir>/src/legacy/core_plugins/$1/public$2',
Copy link
Member

Choose a reason for hiding this comment

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

context is to allow nested folders?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

rather the opposite, to allow importing from the plugin directly, like plugin/data, but to be honest that's not needed anymore so I can actually revert that change here.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Well but since we might hit that problem another time I might just leave it, since you anyway already approved it :)

Copy link
Member

@jbudz jbudz left a comment

Choose a reason for hiding this comment

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

jest config LGTM

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

Copy link
Member

@lukeelmers lukeelmers left a comment

Choose a reason for hiding this comment

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

Just one last question :)

@@ -17,7 +17,7 @@
* under the License.
*/

import { parseInterval } from '../utils/parse_interval';
import { isValidEsInterval } from '../../../core_plugins/data/common';
Copy link
Member

Choose a reason for hiding this comment

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

Are you importing from data/common here instead of data/public to avoid the mocking issues that were surfacing due to all of the stuff that's imported into data/public/index?

Because otherwise I'd suggest importing from data/public since common will be an implementation detail of the plugin in the new platform, and may change.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes that was exactly the fix (that I didn't remember in our last meeting). So basically because of the mocking issues I import directly from common. I also added to the PR description that this is a tech-debt we need to remove later on, once we have a proper solution for the mocking issue with one large entry file (or then potentially another solution).

cc @skaapgif @joshdover This was actually the workaround I used for now, which I forgot about in our last meeting, how I fixed it in this PR :) So simply deep importing from not the top level entry file.

@timroes timroes merged commit 850e7fb into elastic:master Jun 25, 2019
@timroes timroes deleted the date-histogram-interval branch June 25, 2019 07:32
timroes pushed a commit to timroes/kibana that referenced this pull request Jun 25, 2019
* Add dateHistogramInterval utility

* Fix editor bug

* Fix tests

* FIx imports to temporary solution

* Remove wrongly merged translations

* Remove old static.ts file
timroes pushed a commit that referenced this pull request Jun 25, 2019
* Add dateHistogramInterval utility

* Fix editor bug

* Fix tests

* FIx imports to temporary solution

* Remove wrongly merged translations

* Remove old static.ts file
@elasticmachine
Copy link
Contributor

💚 Build Succeeded

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature:Aggregations Aggregation infrastructure (AggConfig, esaggs, ...) release_note:enhancement Team:Visualizations Visualization editors, elastic-charts and infrastructure v7.3.0 v8.0.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants