Hi there,
I just used the elasticsearch aggregations through the Java API for the
first time.
All I wanted was a simple min/max/sum/avg, so I used the Stats aggregation.
However, I was very surprised that the filter in the SearchRequestBuilder
is ignored, so I had to wrap the Stats Aggregation into FilterAggregation.
Getting the aggregation result seems a bit tedious:
Maybe I am using the Java API wrong (I hope I am, otherwise it's imho
poorly designed.) Can anyone point me to an example how to access the
aggregation results from Java better?
Also, I think that the aggregation should be filtered by default. If I
specify the filter with a query or post filter:
and then add an aggregation GET to the same searchRequestBuilder, I think
it's very unintuitive if the aggregation is computed globally. Anyone has
this feeling as well?
The aggregation takes into account a query - but not a post-filter. I'm not
sure of the rationale behind the difference.
The java api for traversing results is quite painful - but I think a good
part of that is due to Java & the fact that there is very little
polymorphic behaviour between aggregation results (some have single
results, others have buckets, some have sub-aggregations, some dont).
The only alternative that I can think of is a completely type-less
navigation of the data - which does little more than navigate the JSON
document.
Hope that helps a bit.
On Monday, 8 September 2014 10:26:44 UTC+1, Emanuel Buzek wrote:
Hi there,
I just used the elasticsearch aggregations through the Java API for the
first time.
All I wanted was a simple min/max/sum/avg, so I used the Stats
aggregation. However, I was very surprised that the filter in the
SearchRequestBuilder is ignored, so I had to wrap the Stats Aggregation
into FilterAggregation.
Getting the aggregation result seems a bit tedious:
Maybe I am using the Java API wrong (I hope I am, otherwise it's imho
poorly designed.) Can anyone point me to an example how to access the
aggregation results from Java better?
Also, I think that the aggregation should be filtered by default. If I
specify the filter with a query or post filter:
and then add an aggregation GET to the same searchRequestBuilder, I think
it's very unintuitive if the aggregation is computed globally. Anyone has
this feeling as well?
Which filter was ignored? I am assuming you meant the post filter (which
might be still called filter at the Java API), which in this case the
filter is bypassed by design. Post filters allow you to filter the
documents returned, but leave the aggregations as is. Sounds like you are
looking for filtered queries. The method name is ambiguous, which is why it
has been renamed (and should actually be deprecated in the API).
Best way to learn the Java API is via the unit tests, but I do agree, there
is no clean way to write elegant code due to explicit casting.
The aggregation takes into account a query - but not a post-filter. I'm
not sure of the rationale behind the difference.
The java api for traversing results is quite painful - but I think a good
part of that is due to Java & the fact that there is very little
polymorphic behaviour between aggregation results (some have single
results, others have buckets, some have sub-aggregations, some dont).
The only alternative that I can think of is a completely type-less
navigation of the data - which does little more than navigate the JSON
document.
Hope that helps a bit.
On Monday, 8 September 2014 10:26:44 UTC+1, Emanuel Buzek wrote:
Hi there,
I just used the elasticsearch aggregations through the Java API for the
first time.
All I wanted was a simple min/max/sum/avg, so I used the Stats
aggregation. However, I was very surprised that the filter in the
SearchRequestBuilder is ignored, so I had to wrap the Stats Aggregation
into FilterAggregation.
Getting the aggregation result seems a bit tedious:
Maybe I am using the Java API wrong (I hope I am, otherwise it's imho
poorly designed.) Can anyone point me to an example how to access the
aggregation results from Java better?
Also, I think that the aggregation should be filtered by default. If I
specify the filter with a query or post filter:
and then add an aggregation GET to the same searchRequestBuilder, I think
it's very unintuitive if the aggregation is computed globally. Anyone has
this feeling as well?
Yes, it was the post filter which was ignored. We use filtered query only
when the user sends a query string, otherwise (when only exact filters for
specific columns are specified) we use the post filter. It seems strange to
me to use the FilteredQuery when the query string is empty, but perhaps
that would be the most straight forward way of doing this.
thank you,
emanuel
Dne pondělí, 8. září 2014 17:21:21 UTC+2 Ivan Brusic napsal(a):
Which filter was ignored? I am assuming you meant the post filter (which
might be still called filter at the Java API), which in this case the
filter is bypassed by design. Post filters allow you to filter the
documents returned, but leave the aggregations as is. Sounds like you are
looking for filtered queries. The method name is ambiguous, which is why it
has been renamed (and should actually be deprecated in the API).
Best way to learn the Java API is via the unit tests, but I do agree,
there is no clean way to write elegant code due to explicit casting.
On Mon, Sep 8, 2014 at 5:41 AM, mooky <nick.mi...@gmail.com <javascript:>>
wrote:
The aggregation takes into account a query - but not a post-filter. I'm
not sure of the rationale behind the difference.
The java api for traversing results is quite painful - but I think a good
part of that is due to Java & the fact that there is very little
polymorphic behaviour between aggregation results (some have single
results, others have buckets, some have sub-aggregations, some dont).
The only alternative that I can think of is a completely type-less
navigation of the data - which does little more than navigate the JSON
document.
Hope that helps a bit.
On Monday, 8 September 2014 10:26:44 UTC+1, Emanuel Buzek wrote:
Hi there,
I just used the elasticsearch aggregations through the Java API for the
first time.
All I wanted was a simple min/max/sum/avg, so I used the Stats
aggregation. However, I was very surprised that the filter in the
SearchRequestBuilder is ignored, so I had to wrap the Stats Aggregation
into FilterAggregation.
Getting the aggregation result seems a bit tedious:
Maybe I am using the Java API wrong (I hope I am, otherwise it's imho
poorly designed.) Can anyone point me to an example how to access the
aggregation results from Java better?
Also, I think that the aggregation should be filtered by default. If I
specify the filter with a query or post filter:
and then add an aggregation GET to the same searchRequestBuilder, I
think it's very unintuitive if the aggregation is computed globally. Anyone
has this feeling as well?
A filtered query with no explicit query will ultimately be translated into
a match-all/constant-score query at the Lucene level. I prefer to
explicitly define all my match all queries and use the specific post filter
name, and not the old filter name, which was deprecated due to its
ambiguity.
Besides, even if you did not have aggregations, you want to do as much
pre-filtered as you can. Post filters work on documents that have been
scored. No need to score documents that will eventually be filtered. Post
filters have some benefits, but it seems like they do not apply in this
case.
Yes, it was the post filter which was ignored. We use filtered query only
when the user sends a query string, otherwise (when only exact filters for
specific columns are specified) we use the post filter. It seems strange to
me to use the FilteredQuery when the query string is empty, but perhaps
that would be the most straight forward way of doing this.
thank you,
emanuel
Dne pondělí, 8. září 2014 17:21:21 UTC+2 Ivan Brusic napsal(a):
Which filter was ignored? I am assuming you meant the post filter (which
might be still called filter at the Java API), which in this case the
filter is bypassed by design. Post filters allow you to filter the
documents returned, but leave the aggregations as is. Sounds like you are
looking for filtered queries. The method name is ambiguous, which is why it
has been renamed (and should actually be deprecated in the API).
Best way to learn the Java API is via the unit tests, but I do agree,
there is no clean way to write elegant code due to explicit casting.
The aggregation takes into account a query - but not a post-filter. I'm
not sure of the rationale behind the difference.
The java api for traversing results is quite painful - but I think a
good part of that is due to Java & the fact that there is very little
polymorphic behaviour between aggregation results (some have single
results, others have buckets, some have sub-aggregations, some dont).
The only alternative that I can think of is a completely type-less
navigation of the data - which does little more than navigate the JSON
document.
Hope that helps a bit.
On Monday, 8 September 2014 10:26:44 UTC+1, Emanuel Buzek wrote:
Hi there,
I just used the elasticsearch aggregations through the Java API for the
first time.
All I wanted was a simple min/max/sum/avg, so I used the Stats
aggregation. However, I was very surprised that the filter in the
SearchRequestBuilder is ignored, so I had to wrap the Stats Aggregation
into FilterAggregation.
Getting the aggregation result seems a bit tedious:
Maybe I am using the Java API wrong (I hope I am, otherwise it's imho
poorly designed.) Can anyone point me to an example how to access the
aggregation results from Java better?
Also, I think that the aggregation should be filtered by default. If I
specify the filter with a query or post filter:
and then add an aggregation GET to the same searchRequestBuilder, I
think it's very unintuitive if the aggregation is computed globally. Anyone
has this feeling as well?
Ivan, thanks a lot for the reply, I switched to FilteredQuery (using
matchAll when no query is submitted) and that simplified my code a lot. It
also makes more sense than using post filters and filtered aggregations...
best, emanuel
Dne úterý, 9. září 2014 18:46:25 UTC+2 Ivan Brusic napsal(a):
A filtered query with no explicit query will ultimately be translated into
a match-all/constant-score query at the Lucene level. I prefer to
explicitly define all my match all queries and use the specific post filter
name, and not the old filter name, which was deprecated due to its
ambiguity.
Besides, even if you did not have aggregations, you want to do as much
pre-filtered as you can. Post filters work on documents that have been
scored. No need to score documents that will eventually be filtered. Post
filters have some benefits, but it seems like they do not apply in this
case.
--
Ivan
On Tue, Sep 9, 2014 at 2:26 AM, Emanuel Buzek <emanue...@roke.cz
<javascript:>> wrote:
Thanks Ivan.
Yes, it was the post filter which was ignored. We use filtered query only
when the user sends a query string, otherwise (when only exact filters for
specific columns are specified) we use the post filter. It seems strange to
me to use the FilteredQuery when the query string is empty, but perhaps
that would be the most straight forward way of doing this.
thank you,
emanuel
Dne pondělí, 8. září 2014 17:21:21 UTC+2 Ivan Brusic napsal(a):
Which filter was ignored? I am assuming you meant the post filter (which
might be still called filter at the Java API), which in this case the
filter is bypassed by design. Post filters allow you to filter the
documents returned, but leave the aggregations as is. Sounds like you are
looking for filtered queries. The method name is ambiguous, which is why it
has been renamed (and should actually be deprecated in the API).
Best way to learn the Java API is via the unit tests, but I do agree,
there is no clean way to write elegant code due to explicit casting.
The aggregation takes into account a query - but not a post-filter. I'm
not sure of the rationale behind the difference.
The java api for traversing results is quite painful - but I think a
good part of that is due to Java & the fact that there is very little
polymorphic behaviour between aggregation results (some have single
results, others have buckets, some have sub-aggregations, some dont).
The only alternative that I can think of is a completely type-less
navigation of the data - which does little more than navigate the JSON
document.
Hope that helps a bit.
On Monday, 8 September 2014 10:26:44 UTC+1, Emanuel Buzek wrote:
Hi there,
I just used the elasticsearch aggregations through the Java API for
the first time.
All I wanted was a simple min/max/sum/avg, so I used the Stats
aggregation. However, I was very surprised that the filter in the
SearchRequestBuilder is ignored, so I had to wrap the Stats Aggregation
into FilterAggregation.
Getting the aggregation result seems a bit tedious:
Maybe I am using the Java API wrong (I hope I am, otherwise it's imho
poorly designed.) Can anyone point me to an example how to access the
aggregation results from Java better?
Also, I think that the aggregation should be filtered by default. If I
specify the filter with a query or post filter:
and then add an aggregation GET to the same searchRequestBuilder, I
think it's very unintuitive if the aggregation is computed globally. Anyone
has this feeling as well?
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.