Skip to content

extended_bounds type on DateHistogram #2828

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

Closed
FabienLavocat opened this issue Aug 10, 2017 · 5 comments
Closed

extended_bounds type on DateHistogram #2828

FabienLavocat opened this issue Aug 10, 2017 · 5 comments

Comments

@FabienLavocat
Copy link
Contributor

NEST/Elasticsearch.Net version: NEST 5.5.0
Elasticsearch version: 5.5.1
Description of the problem including expected versus actual behavior: The class DateHistogramAggregation has a property ExtendedBounds with the type ExtendedBounds<DateTime>
I think this type should be more generic. Having the type ExtendedBounds<DateMath> would make it easier to use values like "now-1d".

In a JSON message, I can send the following:

"over_time" : {
  "date_histogram" : {
  "field" : "date",
  "interval" : "hour",
  "extended_bounds": {
   "min": "now-12h",
   "max": "now"
  }
 }
}

PS: I can send a PR if needed.

@russcam
Copy link
Contributor

russcam commented Aug 10, 2017

Hey @FabienLavocat, thanks for reporting this.

I agree that supporting ExtendedBounds<DateMath> would be much better and a PR against master for this would be awesome! 👍

It gets a little trickier with 2.x and 5.x branches however; technically changing from ExtendedBounds<DateTime> to ExtendedBounds<DateMath> would be a binary breaking change, although there is an implicit conversion from DateTime to DateMath .

For binary backwards compatibility, a PR against 5.x and 2.x would need to deprecate the ExtendedBounds<DateTime> property, add a ExtendedBounds<DateMath> with a different name and assign to this when the deprecated property is assigned to, similar to how "rewrite" was handled. If you'd like to submit a PR for this too, it would be greatly appreciated, otherwise could be easily done from a PR against master.

@FabienLavocat
Copy link
Contributor Author

I've made the change in the master branch. I don't think it would be an issue in 5.x since there is the implicit conversion from DateTime to DateMath

@russcam
Copy link
Contributor

russcam commented Aug 11, 2017

Thanks for the PR, @FabienLavocat 🎉

The breaking issue is not so much with implicit conversion from DateTime -> DateMath, but more so that the property on the request is ExtendedBounds<DateTime> and changing to ExtendedBounds<DateMath> would be binary breaking change with no implicit conversion.

@FabienLavocat
Copy link
Contributor Author

Oh yes, it makes complete sense. I'll see what's possible for 5.x

russcam added a commit that referenced this issue Dec 17, 2017
Non-binary breaking backport of #2829

Closes #2828
russcam added a commit that referenced this issue Dec 18, 2017
Non-binary breaking backport of #2829

Closes #2828
russcam added a commit that referenced this issue Dec 18, 2017
Non-binary breaking backport of #2829

Closes #2828

(cherry picked from commit f640b05)
@russcam
Copy link
Contributor

russcam commented Dec 20, 2017

Closing this as PRs merged for the next releases. Thanks for opening @FabienLavocat 👍

@russcam russcam closed this as completed Dec 20, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants