[ 
https://issues.apache.org/jira/browse/SOLR-9510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15600214#comment-15600214
 ] 

Yonik Seeley commented on SOLR-9510:
------------------------------------

Multi-select faceting (see http://yonik.com/multi-select-faceting/ for those 
new to the concept) works off of tagging top-level filters (fq parameters) and 
then excluding certain filters by-tag before calculating the facets.

One issue we face with parent/child facets is that the original filters used to 
select the child documents (book reviews in our examples) are not top-level 
filters and hence tagging doesn't work.

For example, if our root domain consisted of child documents rather than parent 
documents, then we could have used top-level filters and tagged them:
{code}
fq={!tag=USER}user_s:yonik
fq={!tag=RATING}rating_i:5
{code}
Instead, those "filters" are part of the \{!parent} query and can't currently 
be listed as separate filters, or tagged.
{code}
q={!parent which=type_s:book}user_s:yonik AND rating_i:5
{code}

h3. Minimum Requirements

It appears that the minimum functionality needed to do multi-select faceting 
with child documents is the *filter* functionality specified in the previous 
post.
Since we're starting with the set of all child documents, the domain need not 
be recomputed... straight filtering will do.

Example:  From the books we've already selected (books I've reviewed with a 5 
star rating), we want to show who submitted the most 5 star reviews.  This 
requires that we ignore/exclude the user filter (or alternatively, only include 
the review filter).
{code}
json.facet={
  top_reviewers : {
     type : terms,
     field : user_s,
     domain: { blockChild : "type_s:book" },
     filter : { "rating_i:5" }
}
{code}

h4. Avoid Repitition

If one doesn't want to repeat the filters everywhere, there needs to be a 
mechanism to name/tag them so they may be used later by name/tag.
\{!tag=mytag} provides some generic support, but it's less-than friendly when 
it's not used at the top level.

Rather than use generic support, Mikhail gave a specific extension *filter* to 
specify filters as parameter names:
{code}
q={!parent which=type_s:book filter=$review_filter}
review_filter=user_s:yonik
review_filter=rating_i:5
{code}

And given that these are individual queries, it becomes less onerous to tag 
them if desired:
{code}
q={!parent which=type_s:book filter=$review_filter}
review_filter={!tag=USER}user_s:yonik
review_filter={!tag=RATING}rating_i:5
{code}

Then the set of things we would want *filter* to support in the JSON Facet API 
would be:
- including filters by parameter
- including filters by tag
- excluding filters by tag

Example: start with all review filters, but exclude any that restrict rating.
{code}
filter : {
  queryParam : review_filter,  // a query that is retrieved by parameter name
  excludeTags : RATING
}
{code}

Example: start with all review filters, but exclude any filters that restrict 
rating.
{code}
filter : {
  queryParam : review_filter,  // a query that is retrieved by parameter name
  excludeTags : RATING
}
{code}

Example: only apply filters that restrict by user
{code}
filter : {
  includeTags : USER
}
{code}

Important note: this "excludeTags" in the filter block is very different than 
"excludeTags" in the domain block (which actually recomputes the domain 
starting with all documents, but excluding the named filter).

The *\{!filters}* query type Mikhail lays out does the same thing as a generic 
query type and thus would be useful outside of JSON Facets.  

> child level facet exclusions
> ----------------------------
>
>                 Key: SOLR-9510
>                 URL: https://issues.apache.org/jira/browse/SOLR-9510
>             Project: Solr
>          Issue Type: Improvement
>      Security Level: Public(Default Security Level. Issues are Public) 
>          Components: Facet Module, faceting, query parsers
>            Reporter: Mikhail Khludnev
>
> h2. Challenge
> * Since SOLR-5743 achieved block join child level facets with counts roll-up 
> to parents, there is a demand for filter exclusions. 
> h2. Context
> * Then, it's worth to consider JSON Facets as an engine for this 
> functionality rather than support a separate component. 
> * During a discussion in SOLR-8998 [a solution for block join with child 
> level 
> exclusion|https://issues.apache.org/jira/browse/SOLR-8998?focusedCommentId=15487095&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15487095]
>  has been found.  
>    
> h2. Proposal
> It's proposed to provide a bit of syntax sugar to make it user friendly, 
> believe it or not.
> h2. List of improvements
> * introducing a local parameter {{filters}} for {{\{!parent}} query parser 
> referring to _multiple_ filters queries via parameter name: {{\{!parent 
> filters=$child.fq ..}..&child.fq=color:Red&child.fq=size:XL}} 
> these _filters_ are intersected with a child query supplied as a subordinate 
> clause.
> * introducing {{\{!filters params=$child.fq excludeTags=color 
> v=$subq}&subq=text:word&child.fq={!tag=color}color:Red&child.fq=size:XL}} it 
> intersects a subordinate clause (here it's {{subq}} param, and the trick is 
> to refer to the same query from {{\{!parent}}}), with multiple filters 
> supplied via parameter name {{params=$child.fq}}, it also supports 
> {{excludeTags}}.
> h2. Notes
> Regarding the latter parser, the alternative approach might be to move into 
> {{domain:\{..}}} instruction of json facet. From the implementation 
> perspective, it's desired to optimize with bitset processing, however I 
> suppose it's might be deferred until some initial level of maturity.     
> h2. Example
> {code}
> q={!parent which=type_s:book filters=$child.fq 
> v=$childquery}&childquery=comment_t:good&child.fq={!tag=author}author_s:yonik&child.fq={!tag=stars}stars_i:(5
>  3)&wt=json&indent=on&json.facet={
> comments_for_author:{
>   type:query,
>   q:"{!filters params=$child.fq excludeTags=author v=$childquery}",
>   "//note":"author filter is excluded",
>   domain:{
>      blockChildren:"type_s:book",
>      "//":"applying filters here might be more promising"
>    }, facet:{
>    authors:{
>       type:terms,
>       field:author_s,
>       facet: {
>           in_books: "unique(_root_)"
>         }
>     }
>    }
> } ,
> comments_for_stars:{
>   type:query,
>  q:"{!filters params=$child.fq excludeTags=stars v=$childquery}",
>   "//note":"stars_i filter is excluded",
>   domain:{
>      blockChildren:"type_s:book"
>    }, facet:{
>    stars:{
>       type:terms,
>       field:stars_i,
>       facet: {
>           in_books: "unique(_root_)"
>         }
>     }
>   }
> }
> }
> {code} 
> Votes? Opinions?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to