[
https://issues.apache.org/jira/browse/SOLR-18256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18096274#comment-18096274
]
Chris M. Hostetter commented on SOLR-18256:
-------------------------------------------
{quote}I think code that calls out to a QParser explicitly has the
responsibility to consider different query shapes in response – shouldn't
assume that a {{*:*}} is absent. What I propose we do is change this behavior
as the contributor is doing, but guard it by a luceneMatchVersion check.
{quote}
I'm not sure i understand what you mean by "shouldn't assume that a {{*:*}} is
absent"
I agree in general with the idea in that people calling out to QParsers
shouldn't make assumptions – either about what the user is passing in, or what
the QParser is producing – but the fact remains that _today_ a plugin can
document itself as...
{quote}This request handler expects a query string in
{{my_custom_request_param}} and does XYZ with each clause of the resulting query
{quote}
...and then that request handler can be implemented (very similar to what
DisMax does today with BQ param) like so...
{code:java}
if (null != my_custom_request_param) {
Query raw = QParser.getParser(my_custom_request_param, req).getQuery();
if (raw instanceof BooleanQuery bool) {
for (BooleanClause c : bool.clauses()) {
// Do XYZ with c
}
} else {
// Do XYZ with raw
}
}
{code}
...and _today_ this plugin will get different behavior depending on which of
these the inputs the request has...
{noformat}
A) my_custom_request_param=-foo
B) my_custom_request_param=*:* -foo
{noformat}
...but *WITH* the linked PR (unless i'm missunderstanding) then the plugin will
*never* be able to tell the difference between "A" and "B" and won't know what
the user intended.
{quote}... What I propose we do is change this behavior as the contributor is
doing, but guard it by a luceneMatchVersion check.
{quote}
I think {{luceneMatchVersion}} checks are great for back compat behavior, but
they don't do anything to give plugin authors control – as i suggested before,
i think this "auto-fix pure negative" behavior should be gated by a QParser
flag (or other first order setter method) and make the default value of that
_flag_ be determined by {{luceneMatchVersion}} so that the QParser docs can be
clear:
{quote}if callers explicitly do/don't want pure negative boolean queries to be
fixed behavior, call {{{}QParser.setAutoFixPureNegative(true|false){}}}. The
default behavior depends on {{luceneMatchVersion}}
{quote}
> 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]
