Is it practical to have an optimised/flexible implementations?
Re-reading, that sentence doesn't make sense.
What I meant to ask is whether it would be practical to have 2
implementations - an optimised one and a flexible one?
-Nick
On Wednesday, 12 March 2014 11:09:44 UTC, mooky wrote:
Actually, yes, it should be
Overdue: date *=* 2014-02-19
March: 2014-02-20 *=* date *=* 2014-03-19
April: 2014-03-20 *=* date *=* 2014-04-16
Yeah, I can add a day to the upper-range to work around this (its what I
have to do now).
However, it also means I have to then subtract a day when taking
Yes? No?
-Nick
On Friday, 7 March 2014 11:46:48 UTC, mooky wrote:
Hi Clinton
I am doing a date-range aggregation - the ranges are defined by
(financial) exchange rules - and they are just dates (LocalDate's) (ie
there is no time component). The *end* of the period is what is defined
by
On 7 March 2014 12:46, mooky nick.minute...@gmail.com wrote:
So the previous, current and next period-end dates are:
2014-02-19, 2014-03-19 2014-04-16.
I define the ranges therefore as:
Overdue: date *2014-02-19*
March: 2014-02-20 date *2014-03-19*
April: 2014-03-20 date *2014-04-16*
Does anyone think this is a worthwhile change?
On Wednesday, 26 February 2014 12:41:53 UTC, mooky wrote:
I think its necessary to be able to specify an *include_lower*/
*include_upper* option like with filters.
On Tuesday, 25 February 2014 14:54:24 UTC, Binh Ly wrote:
Yes, you are
I think its necessary to be able to specify an *include_lower*/
*include_upper* option like with filters.
On Tuesday, 25 February 2014 14:54:24 UTC, Binh Ly wrote:
Yes, you are correct. The from is inclusive, and the to is exclusive.
--
You received this message because you are subscribed
Yes, you are correct. The from is inclusive, and the to is exclusive.
--
You received this message because you are subscribed to the Google Groups
elasticsearch group.
To unsubscribe from this group and stop receiving emails from it, send an email
to elasticsearch+unsubscr...@googlegroups.com.
What are the expected semantics of the from/to fields in a DateRange
aggregation?
Are the from/to values included? Should there be an *include_lower*/
*include_upper* option like with filters?
I want the aggregation to include the lower and upper values - but I
discovered today that it doesnt
Oops. I copy-pasted the aggregation I was hacking about with.
The actual aggregation looks like this (I had added an additional
millisecond as a hack to include_upper)
aggregations : {
intentDate : {
date_range : {
field : intentDate,
ranges : [ {
key : Overdue,
