[
https://issues.apache.org/jira/browse/SOLR-9519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15555922#comment-15555922
]
Michael Sun commented on SOLR-9519:
-----------------------------------
bq. The domain check may need to be recursive. A direct child may not change
the domain in a non-narrowing way, but a child of that child may.
Thanks [[email protected]] for reviewing. Can you also give an example for this
use case? I tried a query like the following and got expected result.
{code}
curl http://localhost:8983/solr/films/select -d
'q=*:*&fq={!tag=GENRE}genre:xxx``&wt=json&indent=true&json.facet={
top_genre: {
type:terms,
field:genre,
numBucket:true,
limit:3,
domain:{excludeTags:GENRE},
facet: {
top_director: {
type:terms,
field:directed_by,
numBuckets:true,
limit:3,
domain:{excludeTags:GENRE}
}
}
}
}'
{code}
> Check sub-facets of empty facet buckets for operations that may expand the
> domain (like filter exclusions)
> ----------------------------------------------------------------------------------------------------------
>
> Key: SOLR-9519
> URL: https://issues.apache.org/jira/browse/SOLR-9519
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Facet Module
> Reporter: Yonik Seeley
> Attachments: SOLR-9519.patch, SOLR-9519.patch
>
>
> http://markmail.org/message/bgplt2qdxc7gqga5
> {quote}
> 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.
> {quote}
> Aside: not processing empty sets also helped with issues like what junk
> values to fill in for statistics... min, max, average, std, etc. JSON
> doesn't even officially support NaN, so it's nice to be able to leave these
> junk values out in many circumstances.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
