You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Mikhail Khludnev (JIRA)" <ji...@apache.org> on 2018/04/26 21:00:00 UTC
[jira] [Updated] (SOLR-9510) child level facet exclusions
[ https://issues.apache.org/jira/browse/SOLR-9510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mikhail Khludnev updated SOLR-9510:
-----------------------------------
Description:
h1. Caveat SOLR-12275 bug in Solr 7.3
{{\{!filters}}} as wells as {{filters}} local param in {{\{!parent filters=...}...}} and {{\{!child filters=..}...}} is broken in 7.3, workaround is adding {{cache=false}} as a local parameter. SOLR-12275 is fixed in Solr 7.4.
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 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 param=$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 {{param=$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:java}
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 param=$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 param=$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?
was:
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 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 param=$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 {{param=$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:java}
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 param=$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 param=$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?
> 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
> Assignee: Mikhail Khludnev
> Priority: Major
> Fix For: 7.3, master (8.0)
>
> Attachments: SOLR-9510-doc.patch, SOLR-9510-doc.patch, SOLR-9510-doc.patch, SOLR-9510.patch, SOLR_9510.patch, SOLR_9510.patch, SOLR_9510.patch, SOLR_9510.patch, SOLR_9510.patch, SOLR_9510.patch, SOLR_9510.patch, SOLR_9510.patch, SOLR_9510.patch, SOLR_9510.patch, SOLR_9510.patch, SOLR_9510.patch, SOLR_9510.patch, SOLR_9510.patch, SOLR_9510.patch
>
>
> h1. Caveat SOLR-12275 bug in Solr 7.3
> {{\{!filters}}} as wells as {{filters}} local param in {{\{!parent filters=...}...}} and {{\{!child filters=..}...}} is broken in 7.3, workaround is adding {{cache=false}} as a local parameter. SOLR-12275 is fixed in Solr 7.4.
> 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 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 param=$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 {{param=$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:java}
> 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 param=$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 param=$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
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org