[
https://issues.apache.org/jira/browse/SOLR-18256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18095324#comment-18095324
]
David Smiley commented on SOLR-18256:
-------------------------------------
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 luceneMatchVersion check. I'm aware the
name of that config element hasn't aged well Since the project split and isn't
documented well... but it's something. WDYT [~hossman] ?
> 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]
