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
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
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
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/toclint
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/toclint
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
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
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
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
What is the status of this feature? Facet ranges still do not appear to support "gt", "gte", "lt", "lte"...
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
Sent from the Elasticsearch Users mailing list archive at Nabble.com (http://Nabble.com).
Hi there,
any news on this ? that would be useful.
By the way I updated the documentation to mention this behavior.
Julien.
© 2020. All Rights Reserved - Elasticsearch
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant logo are trademarks of the Apache Software Foundation in the United States and/or other countries.