[
https://issues.apache.org/jira/browse/SOLR-18256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18097923#comment-18097923
]
Chris M. Hostetter commented on SOLR-18256:
-------------------------------------------
{quote}I'm not sure why such a plugin needs to consider "A" as intended {_}as
distinct from B{_}. Why not always normalize to B? I'm asking... is there
distinct information/intent in "A"? I'm skeptical.
{quote}
The distinct information is "did the user include the first clause, or was it
synthetically added"
As for why a plugin might care – see previous comment...
{quote}...so that custom request handlers that delegated to multiple query
parsers could _CHOOSE_ to take all the BooleanClauses produced by a sub-parser,
and add them "as is" to a new wrapper BooleanQuery. Even if the clauses were
"purely negative" we would assume that's what the user ment.
{quote}
And as i said – for better or worse – dismax still does this _*TODAY:*_ If the
{{bq}} param is a BooleanQuery, it loops over all individual clauses "as is"
and adds them "raw" to it's own wrapper BooleanQuery.
In these kinds of situations, adding a synthetic {{MatchAllQuery()}} _(that
dismax can not distinguished from a MatchAllQuery provided by the user)_ is
going to impact the scores of all documents...
{noformat}
hossman@slate:~$ curl -sS
'http://localhost:8983/solr/demo/select?omitHeader=true&defType=dismax&pf=name&qf=name&q=ipod&fl=id,score&;'
&& echo
{
"response":{
"numFound":3,
"start":0,
"maxScore":2.8935955,
"numFoundExact":true,
"docs":[{
"id":"IW-02",
"score":2.8935955
},{
"id":"F8V7067-APL-KIT",
"score":1.8430278
},{
"id":"MA147LL/A",
"score":1.8430278
}]
}
}
hossman@slate:~$ curl -sS
'http://localhost:8983/solr/demo/select?omitHeader=true&defType=dismax&pf=name&qf=name&q=ipod&fl=id,score&bq=-manu_id_s:apple'
&& echo
{
"response":{
"numFound":2,
"start":0,
"maxScore":2.8935955,
"numFoundExact":true,
"docs":[{
"id":"IW-02",
"score":2.8935955
},{
"id":"F8V7067-APL-KIT",
"score":1.8430278
}]
}
}
hossman@slate:~$ curl -sS
'http://localhost:8983/solr/demo/select?omitHeader=true&defType=dismax&pf=name&qf=name&q=ipod&fl=id,score&bq=*:*+-manu_id_s:apple'
&& echo
{
"response":{
"numFound":2,
"start":0,
"maxScore":3.8935957,
"numFoundExact":true,
"docs":[{
"id":"IW-02",
"score":3.8935957
},{
"id":"F8V7067-APL-KIT",
"score":2.8430278
}]
}
}
{noformat}
> Auto-fix pure negative (NOT) clauses in the "lucene" QParser
> ------------------------------------------------------------
>
> Key: SOLR-18256
> URL: https://issues.apache.org/jira/browse/SOLR-18256
> Project: Solr
> Issue Type: Improvement
> Reporter: David Smiley
> Priority: Major
> Labels: newdev, pull-request-available
> Time Spent: 1h
> Remaining Estimate: 0h
>
> When the lucene query parser parses a negative query — one where all boolean
> clauses are prohibited, such as {{NOT bar}} , possibly as a sub-expression
> (parenthesis wrapped) — the resulting {{BooleanQuery}} matches no documents.
> This is not what people intuitively expect. I've seen code work around this,
> and it's really annoying. I've also seen code _forget_ to do this, resulting
> in undesired behavior. This has been a long-standing gotcha to stub your toe
> on with Solr development.
> While it can be argued the fix should be in Lucene, I think Lucene is
> stubborn on this point, as there is _some_ sense in the current behavior. I
> may pursue an opt-in improvement to BooleanQuery.Builder.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
