[
https://issues.apache.org/jira/browse/SOLR-18256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18093524#comment-18093524
]
Chris M. Hostetter edited comment on SOLR-18256 at 7/3/26 7:45 PM:
-------------------------------------------------------------------
FWIW: The reason I never made a change like this way, way, WAY, back in the
day, was 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.
This is a contrived example, but consider even dismax to this day – it let's
you take a query like this...
{noformat}
$ curl
'http://localhost:8983/solr/techproducts/select?omitHeader=true&defType=dismax&pf=name&qf=name&q=ipod&fl=id&debug=query'
{
"response":{
"numFound":3,
"start":0,
"numFoundExact":true,
"docs":[{
"id":"IW-02"
},{
"id":"F8V7067-APL-KIT"
},{
"id":"MA147LL/A"
}]
},
"debug":{
"rawquerystring":"ipod",
"querystring":"ipod",
"parsedquery":"+DisjunctionMaxQuery((name:ipod))
DisjunctionMaxQuery((name:ipod))",
"parsedquery_toString":"+(name:ipod) (name:ipod)",
"QParser":"DisMaxQParser",
"altquerystring":null,
"boostfuncs":null
}
}{noformat}
and then let's do stuff like this when you add a "purely negative" {{bq}} param
(NOTE the change in {{numFound}} ) ...
{noformat}
$ curl
'http://localhost:8983/solr/techproducts/select?omitHeader=true&defType=dismax&pf=name&qf=name&q=ipod&fl=id&debug=query&bq=-manu_id_s:appl''
{
"response":{
"numFound":2,
"start":0,
"numFoundExact":true,
"docs":[{
"id":"IW-02"
},{
"id":"F8V7067-APL-KIT"
}]
},
"debug":{
"rawquerystring":"ipod",
"querystring":"ipod",
"parsedquery":"+DisjunctionMaxQuery((name:ipod))
DisjunctionMaxQuery((name:ipod)) -manu_id_s:apple",
"parsedquery_toString":"+(name:ipod) (name:ipod) -manu_id_s:apple",
"QParser":"DisMaxQParser",
"altquerystring":null,
"boost_queries":["-manu_id_s:apple"],
"parsed_boost_queries":["-manu_id_s:apple"],
"boostfuncs":null
}
}{noformat}
* is this good behavior for dismax to have?
* is this bad behavior for dismax to have?
* does the PR change the backcompat of this behavior? ... does it matter?
I don't know the right answer to any of those questions ... what I do know is
20 years ago I had custom request handlers that depending on this behavior of
the solr query parsers ... which makes me wonder...
{panel:title="?? The Big Question ??"}
* If the PR gets committed, then how would someone writing a custom request
handler, that wants to run a QParser over a {{my_custom_request_param}} and
manipulate the resulting query, be able to tell the difference between a user
providing
** {{my_custom_request_param=-foo}}
** vs: {{my_custom_request_param=*:* -foo}}
* should there be a QParser flag or something that disables this?
* or is this such a niche concern that we shouldn't worry about it?{panel}
was (Author: hossman):
FWIW: The reason I never made a change like this way, way, WAY, back in the
day, was 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.
This is a contrived example, but consider even dismax to this day – it let's
you take a query like this...
{noformat}
$ curl
'http://localhost:8983/solr/techproducts/select?omitHeader=true&defType=dismax&pf=name&qf=name&q=ipod&fl=id&debug=query'
{
"response":{
"numFound":3,
"start":0,
"numFoundExact":true,
"docs":[{
"id":"IW-02"
},{
"id":"F8V7067-APL-KIT"
},{
"id":"MA147LL/A"
}]
},
"debug":{
"rawquerystring":"ipod",
"querystring":"ipod",
"parsedquery":"+DisjunctionMaxQuery((name:ipod))
DisjunctionMaxQuery((name:ipod))",
"parsedquery_toString":"+(name:ipod) (name:ipod)",
"QParser":"DisMaxQParser",
"altquerystring":null,
"boostfuncs":null
}
}{noformat}
and then let's do stuff like this when you add a "purely negative" {{bq}} param
(not the change in {{numFound}} ) ...
{noformat}
$ curl
'http://localhost:8983/solr/techproducts/select?omitHeader=true&defType=dismax&pf=name&qf=name&q=ipod&fl=id&debug=query&bq=-manu_id_s:appl''
{
"response":{
"numFound":2,
"start":0,
"numFoundExact":true,
"docs":[{
"id":"IW-02"
},{
"id":"F8V7067-APL-KIT"
}]
},
"debug":{
"rawquerystring":"ipod",
"querystring":"ipod",
"parsedquery":"+DisjunctionMaxQuery((name:ipod))
DisjunctionMaxQuery((name:ipod)) -manu_id_s:apple",
"parsedquery_toString":"+(name:ipod) (name:ipod) -manu_id_s:apple",
"QParser":"DisMaxQParser",
"altquerystring":null,
"boost_queries":["-manu_id_s:apple"],
"parsed_boost_queries":["-manu_id_s:apple"],
"boostfuncs":null
}
}{noformat}
* is this good behavior for dismax to have?
* is this bad behavior for dismax to have?
* does the PR change the backcompat of this behavior? ... does it matter?
I don't know the right answer to any of those questions ... what I do know is
20 years ago I had custom request handlers that depending on this behavior of
the solr query parsers ... which makes me wonder...
{panel:title="?? The Big Question ??"}
* If the PR gets committed, then how would someone writing a custom request
handler, that wants to run a QParser over a {{my_custom_request_param}} and
manipulate the resulting query, be able to tell the difference between a user
providing
** {{my_custom_request_param=-foo}}
** vs: {{my_custom_request_param=\*:\* -foo}}
* should there be a QParser flag or something that disables this?
* or is this such a niche concern that we shouldn't worry about it?{panel}
> 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: 50m
> 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]
