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 <emanuel.bu...@roke.cz> 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. >> >> https://github.com/elasticsearch/elasticsearch/ >> tree/master/src/test/java/org/elasticsearch/search/aggregations >> >> Cheers, >> >> Ivan >> >> >> On Mon, Sep 8, 2014 at 5:41 AM, mooky <nick.mi...@gmail.com> 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: >>>> >>>> InternalStats stats = (InternalStats)((InternalFilter)a). >>>> getAggregations().asList().get(0); >>>> >>>> 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: >>>> >>>> queryBuilder = QueryBuilders.filteredQuery(queryBuilder, >>>> filterBuilder); >>>> >>>> searchRequestBuilder.setQuery(queryBuilder); >>>> >>>> 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? >>>> >>>> thanks, emanuel >>>> >>>> -- >>>> Emanuel Buzek >>>> Software Engineer, ROKE.cz <http://www.roke.cz> >>>> tel: +420 776 54 26 26 >>>> >>> -- >>> 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 elasticsearc...@googlegroups.com. >>> To view this discussion on the web visit https://groups.google.com/d/ >>> msgid/elasticsearch/a2e3a1e1-912a-4257-b938-6036d0c9d3ff% >>> 40googlegroups.com >>> <https://groups.google.com/d/msgid/elasticsearch/a2e3a1e1-912a-4257-b938-6036d0c9d3ff%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- > 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. > To view this discussion on the web visit > https://groups.google.com/d/msgid/elasticsearch/1eb0e2c2-91e9-43b0-b076-decd33fa6440%40googlegroups.com > <https://groups.google.com/d/msgid/elasticsearch/1eb0e2c2-91e9-43b0-b076-decd33fa6440%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CALY%3DcQCwrV%3DS2-%2BS0GLr95LoSHCxsxCfFWqc88D6bffDr1WMFw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
