On Wed, Sep 14, 2016 at 10:12 AM, Stefan Matheis <[email protected]> wrote: > I’m not entirely sure i’m describing the correct problem here - for now it > looks like the only way it occurs and i hope it’s not misleading any pointers > that would be helpful. so in case you think i got it wrong, please say so > > I have two documents in the index [{"source":"foo"}, {"source":"bar”}] where > source is a simple string field (indexed as well as stored, if that’ll > matter). > > Using > >> ?q=*:* >> &fq={!tag=source}source:"meh" >> &json.facet={"source":{"type":"terms","field":"source","domain":{"excludeTags":"source"}}} > > where meh is a value that is not available for source, i get no results > (expected) but no facets as well - which is rather unexpected to me. as soon > as i go with source:”bar” (or something else that yields at least one record) > i’m getting a record back and as well facets.
A case this simple should be categorized as a bug... Background: the JSON Facet API does not execute sub-facets for a facet bucket with a 0 count (and the root facet bucket is like any other facet bucket). This was to help prevent the combinatorial explosion of deeply nested sub-facets with useless information. This is obviously incorrect though, when a sub-facet does something that can expand the domain rather than just restrict it. Facet exclusions are one of these cases. For zero facet buckets, we should check if any sub-facets have these properties and then recurse if so. -Yonik > which is why i’ve started of with the idea that there might be a correlation > between those things. verifying the situation using the old facet approach i > always get the expected facets back, no matter if the result is empty or not. > > Or isn’t it supposed to work like this anymore and i’m the guy who didn’t get > the memo? > > Thanks > Stefan >
