# Lower and upper bound of range facet is not consistent with RangeQuery **URL:** \ **Category:** Elasticsearch\ **Created:** [June 28, 2011, 11:30pm UTC](https://discuss.elastic.co/t/lower-and-upper-bound-of-range-facet-is-not-consistent-with-rangequery/4728 "2011-06-28T23:30:42Z")\ **Posts on this page:** 13\ **Page:** 1
**Author:** ![Stephane\_Bastian](https://avatars.discourse-cdn.com/v4/letter/s/35a633/32.png) [@Stephane\_Bastian](https://discuss.elastic.co/u/Stephane_Bastian)\ **Post date:** [June 28, 2011, 11:30pm UTC](https://discuss.elastic.co/t/lower-and-upper-bound-of-range-facet-is-not-consistent-with-rangequery/4728/1 "2011-06-28T23:30:42Z")
Hi, I've just noticed that the range facet includes the 'from' value and excludes the 'to' value from its results. It's fine but is not consistent with RangeQuery which by default includes both the 'from' and 'to' values. Do you guys feel that both range facet and range query should support the same default behavior? Should I log a bug for this? Cheers ---
**Author:** ![kimchy](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/kimchy/32/44952_2.png) [@kimchy](https://discuss.elastic.co/u/kimchy)\ **Post date:** [June 29, 2011, 12:05pm UTC](https://discuss.elastic.co/t/lower-and-upper-bound-of-range-facet-is-not-consistent-with-rangequery/4728/2 "2011-06-29T12:05:55Z")
Yea, it is different... . One of the reasoning for that is that you don't have the option to set if lower and upper should be included or not, compared to range filter, where you have that option. On Wednesday, June 29, 2011 at 2:30 AM, stephane wrote: > Hi, > > I've just noticed that the range facet includes the 'from' value and > excludes the 'to' value from its results. > It's fine but is not consistent with RangeQuery which by default > includes both the 'from' and 'to' values. > > Do you guys feel that both range facet and range query should support > the same default behavior? > Should I log a bug for this? > > Cheers ---
**Author:** ![Clinton\_Gormley](https://avatars.discourse-cdn.com/v4/letter/c/50afbb/32.png) [@Clinton\_Gormley](https://discuss.elastic.co/u/Clinton_Gormley)\ **Post date:** [June 29, 2011, 12:10pm UTC](https://discuss.elastic.co/t/lower-and-upper-bound-of-range-facet-is-not-consistent-with-rangequery/4728/3 "2011-06-29T12:10:53Z")
On Wed, 2011-06-29 at 15:05 +0300, Shay Banon wrote: > Yea, it is different... . One of the reasoning for that is that you > don't have the option to set if lower and upper should be included or > not, compared to range filter, where you have that option. But don't forget that you can use 'gt','gte','lt','lte' instead of from/to clint ---
**Author:** ![kimchy](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/kimchy/32/44952_2.png) [@kimchy](https://discuss.elastic.co/u/kimchy)\ **Post date:** [June 29, 2011, 12:14pm UTC](https://discuss.elastic.co/t/lower-and-upper-bound-of-range-facet-is-not-consistent-with-rangequery/4728/4 "2011-06-29T12:14:10Z")
You can't use it in the range facet though :), it only supports from/to. It was just me being lazy, we need to add support for similar functionality that we have in range filter to the facet. On Wednesday, June 29, 2011 at 3:10 PM, Clinton Gormley wrote: > On Wed, 2011-06-29 at 15:05 +0300, Shay Banon wrote: > > > Yea, it is different... . One of the reasoning for that is that you > > don't have the option to set if lower and upper should be included or > > not, compared to range filter, where you have that option. > > But don't forget that you can use 'gt','gte','lt','lte' instead of > from/to > > clint ---
**Author:** ![kimchy](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/kimchy/32/44952_2.png) [@kimchy](https://discuss.elastic.co/u/kimchy)\ **Post date:** [June 29, 2011, 12:16pm UTC](https://discuss.elastic.co/t/lower-and-upper-bound-of-range-facet-is-not-consistent-with-rangequery/4728/5 "2011-06-29T12:16:03Z")
Lemme try and explain the reasoning though behind just doing from/to and the fact that to is not included. Basically, it lends itself more towards creating range facet over consecutive ares (like 0-100, 100-1000, 1000-50000), where you don't want to compute the doc twice across boundaries. On Wednesday, June 29, 2011 at 3:14 PM, Shay Banon wrote: > You can't use it in the range facet though :), it only supports from/to. It was just me being lazy, we need to add support for similar functionality that we have in range filter to the facet. > > On Wednesday, June 29, 2011 at 3:10 PM, Clinton Gormley wrote: > > > On Wed, 2011-06-29 at 15:05 +0300, Shay Banon wrote: > > > > > Yea, it is different... . One of the reasoning for that is that you > > > don't have the option to set if lower and upper should be included or > > > not, compared to range filter, where you have that option. > > > > But don't forget that you can use 'gt','gte','lt','lte' instead of > > from/to > > > > clint ---
**Author:** ![Clinton\_Gormley](https://avatars.discourse-cdn.com/v4/letter/c/50afbb/32.png) [@Clinton\_Gormley](https://discuss.elastic.co/u/Clinton_Gormley)\ **Post date:** [June 29, 2011, 12:27pm UTC](https://discuss.elastic.co/t/lower-and-upper-bound-of-range-facet-is-not-consistent-with-rangequery/4728/6 "2011-06-29T12:27:08Z")
On Wed, 2011-06-29 at 15:16 +0300, Shay Banon wrote: > Lemme try and explain the reasoning though behind just doing from/to > and the fact that to is not included. Basically, it lends itself more > towards creating range facet over consecutive ares (like 0-100, > 100-1000, 1000-50000), where you don't want to compute the doc twice > across boundaries. To me, this is not intuitive, especially when the behaviour of the same keyword is different in similar constructs. If I say I'm going to Madrid, I don't mean that I'm going to just outside Madrid. Similarly, just reading the query, and without being aware of the unexpected meaning of 'to', I wouldn't know which range an edge value would fall into. I think it'd be clearer to support the gt,gte etc - that way it is clear which values the range should include or exclude. clint ---
**Author:** ![Stephane\_Bastian](https://avatars.discourse-cdn.com/v4/letter/s/35a633/32.png) [@Stephane\_Bastian](https://discuss.elastic.co/u/Stephane_Bastian)\ **Post date:** [June 29, 2011, 3:47pm UTC](https://discuss.elastic.co/t/lower-and-upper-bound-of-range-facet-is-not-consistent-with-rangequery/4728/7 "2011-06-29T15:47:13Z")
Hi All, As Clinton pointed-out, the think that is not intuitive is the fact that the same keyword behaves differently in similar constructs. That's fairly confusing and unexpected. As a matter of fact, I probably spent 1 hour trying to figure out why the RangeFacet didn't include some results. Then I realized that the meaning of the 'to' field was different. Another thing which is rather confusing is when you use the 'from' and 'to' values of a RangeFacet and create a RangeFilter from them. The confusing part is that the RangeFacet indicates that you'll get say '20' results but the RangeFilter returns more than '20' results (since it includes the 'to' value). I suggest that we add 'gt','gte','lt','lte' to the RangeFacet to mimic the options supported by the RangeFilter. I also suggest that the 'to' value should be included by default. If you guys agree, I can file a bug and create a patch for it. Stephane Bastian On Wed, 2011-06-29 at 14:27 +0200, Clinton Gormley wrote: > On Wed, 2011-06-29 at 15:16 +0300, Shay Banon wrote: > > > Lemme try and explain the reasoning though behind just doing from/to > > and the fact that to is not included. Basically, it lends itself more > > towards creating range facet over consecutive ares (like 0-100, > > 100-1000, 1000-50000), where you don't want to compute the doc twice > > across boundaries. > > To me, this is not intuitive, especially when the behaviour of the same > keyword is different in similar constructs. > > If I say I'm going to Madrid, I don't mean that I'm going to just > outside Madrid. Similarly, just reading the query, and without being > aware of the unexpected meaning of 'to', I wouldn't know which range an > edge value would fall into. > > I think it'd be clearer to support the gt,gte etc - that way it is clear > which values the range should include or exclude. > > clint ---
**Author:** ![kimchy](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/kimchy/32/44952_2.png) [@kimchy](https://discuss.elastic.co/u/kimchy)\ **Post date:** [June 29, 2011, 6:33pm UTC](https://discuss.elastic.co/t/lower-and-upper-bound-of-range-facet-is-not-consistent-with-rangequery/4728/8 "2011-06-29T18:33:37Z")
I agree that we can add more options to define the range aspect, but disagree on the "from" and "to" default behavior for the reason I explained below. Many users do range facets on {from : 0, to: 10}, {from: 10, to: 20), and having to included will simply be wrong (or a wrong default). On Wednesday, June 29, 2011 at 6:47 PM, stephane wrote: > Hi All, > > As Clinton pointed-out, the think that is not intuitive is the fact that > the same keyword behaves differently in similar constructs. That's > fairly confusing and unexpected. As a matter of fact, I probably spent > 1 hour trying to figure out why the RangeFacet didn't include some > results. Then I realized that the meaning of the 'to' field was > different. > > Another thing which is rather confusing is when you use the 'from' and > 'to' values of a RangeFacet and create a RangeFilter from them. The > confusing part is that the RangeFacet indicates that you'll get say '20' > results but the RangeFilter returns more than '20' results (since it > includes the 'to' value). > > I suggest that we add 'gt','gte','lt','lte' to the RangeFacet to mimic > the options supported by the RangeFilter. I also suggest that the 'to' > value should be included by default. > If you guys agree, I can file a bug and create a patch for it. > > Stephane Bastian > > On Wed, 2011-06-29 at 14:27 +0200, Clinton Gormley wrote: > > > On Wed, 2011-06-29 at 15:16 +0300, Shay Banon wrote: > > > > > Lemme try and explain the reasoning though behind just doing from/to > > > and the fact that to is not included. Basically, it lends itself more > > > towards creating range facet over consecutive ares (like 0-100, > > > 100-1000, 1000-50000), where you don't want to compute the doc twice > > > across boundaries. > > > > To me, this is not intuitive, especially when the behaviour of the same > > keyword is different in similar constructs. > > > > If I say I'm going to Madrid, I don't mean that I'm going to just > > outside Madrid. Similarly, just reading the query, and without being > > aware of the unexpected meaning of 'to', I wouldn't know which range an > > edge value would fall into. > > > > I think it'd be clearer to support the gt,gte etc - that way it is clear > > which values the range should include or exclude. > > > > clint ---
**Author:** ![Stephane\_Bastian](https://avatars.discourse-cdn.com/v4/letter/s/35a633/32.png) [@Stephane\_Bastian](https://discuss.elastic.co/u/Stephane_Bastian)\ **Post date:** [July 5, 2011, 4:40pm UTC](https://discuss.elastic.co/t/lower-and-upper-bound-of-range-facet-is-not-consistent-with-rangequery/4728/9 "2011-07-05T16:40:35Z")
I'm lagging behind on this one. so let me open a feature request to add more options (include lower/upper, gte, gt, lte...). I'll also take a stab at implementing the changes and send a pull request if everything is working fine. Right now I'm fighting with Eclipse to get it correctly configured with ES source and gradle dependencies... Stephane On Wed, 2011-06-29 at 21:33 +0300, Shay Banon wrote: > I agree that we can add more options to define the range aspect, but > disagree on the "from" and "to" default behavior for the reason I > explained below. Many users do range facets on {from : 0, to: 10}, > {from: 10, to: 20), and having to included will simply be wrong (or a > wrong default). > > On Wednesday, June 29, 2011 at 6:47 PM, stephane wrote: > > > Hi All, > > > > As Clinton pointed-out, the think that is not intuitive is the fact > > that > > the same keyword behaves differently in similar constructs. That's > > fairly confusing and unexpected. As a matter of fact, I probably > > spent > > 1 hour trying to figure out why the RangeFacet didn't include some > > results. Then I realized that the meaning of the 'to' field was > > different. > > > > Another thing which is rather confusing is when you use the 'from' > > and > > 'to' values of a RangeFacet and create a RangeFilter from them. The > > confusing part is that the RangeFacet indicates that you'll get say > > '20' > > results but the RangeFilter returns more than '20' results (since it > > includes the 'to' value). > > > > I suggest that we add 'gt','gte','lt','lte' to the RangeFacet to > > mimic > > the options supported by the RangeFilter. I also suggest that the > > 'to' > > value should be included by default. > > If you guys agree, I can file a bug and create a patch for it. > > > > Stephane Bastian > > > > On Wed, 2011-06-29 at 14:27 +0200, Clinton Gormley wrote: > > > > > On Wed, 2011-06-29 at 15:16 +0300, Shay Banon wrote: > > > > > > > Lemme try and explain the reasoning though behind just doing > > > > from/to > > > > and the fact that to is not included. Basically, it lends itself > > > > more > > > > towards creating range facet over consecutive ares (like 0-100, > > > > 100-1000, 1000-50000), where you don't want to compute the doc > > > > twice > > > > across boundaries. > > > > > > To me, this is not intuitive, especially when the behaviour of the > > > same > > > keyword is different in similar constructs. > > > > > > If I say I'm going to Madrid, I don't mean that I'm going to just > > > outside Madrid. Similarly, just reading the query, and without > > > being > > > aware of the unexpected meaning of 'to', I wouldn't know which > > > range an > > > edge value would fall into. > > > > > > I think it'd be clearer to support the gt,gte etc - that way it is > > > clear > > > which values the range should include or exclude. > > > > > > clint ---
**Author:** ![my3sons](https://avatars.discourse-cdn.com/v4/letter/m/e274bd/32.png) [@my3sons](https://discuss.elastic.co/u/my3sons)\ **Post date:** [March 10, 2012, 1:23pm UTC](https://discuss.elastic.co/t/lower-and-upper-bound-of-range-facet-is-not-consistent-with-rangequery/4728/10 "2012-03-10T13:23:56Z")
What is the status of this feature? Facet ranges still do not appear to support "gt", "gte", "lt", "lte"... ---
**Author:** ![kimchy](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/kimchy/32/44952_2.png) [@kimchy](https://discuss.elastic.co/u/kimchy)\ **Post date:** [March 14, 2012, 12:54pm UTC](https://discuss.elastic.co/t/lower-and-upper-bound-of-range-facet-is-not-consistent-with-rangequery/4728/11 "2012-03-14T12:54:03Z")
Still not implemented. Though, you can simply use filter cache with a range filter as well. On Saturday, March 10, 2012 at 3:23 PM, my3sons wrote: > What is the status of this feature? Facet ranges still do not appear to > support "gt", "gte", "lt", "lte"... > > -- > View this message in context: [http://elasticsearch-users.115913.n3.nabble.com/Lower-and-upper-bound-of-range-facet-is-not-consistent-with-RangeQuery-tp3119848p3815045.html](http://elasticsearch-users.115913.n3.nabble.com/Lower-and-upper-bound-of-range-facet-is-not-consistent-with-RangeQuery-tp3119848p3815045.html) > Sent from the Elasticsearch Users mailing list archive at [Nabble.com](http://Nabble.com) ([http://Nabble.com](http://Nabble.com)). ---
**Author:** ![themouette](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/themouette/32/2422_2.png) [@themouette](https://discuss.elastic.co/u/themouette)\ **Post date:** [December 21, 2012, 3:55pm UTC](https://discuss.elastic.co/t/lower-and-upper-bound-of-range-facet-is-not-consistent-with-rangequery/4728/12 "2012-12-21T15:55:13Z")
Hi there, any news on this ? that would be useful. By the way I updated the documentation to mention this behavior. Julien. ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 6, 2017, 2:58am UTC](https://discuss.elastic.co/t/lower-and-upper-bound-of-range-facet-is-not-consistent-with-rangequery/4728/13 "2017-07-06T02:58:44Z")