[
https://issues.apache.org/jira/browse/LUCENE-3460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13114414#comment-13114414
]
Hoss Man commented on LUCENE-3460:
----------------------------------
a) watch out how/if you remove QueryUtils.makeQueryable ... this "hack" isn't
just about adding a MatchAllDocsQuery, it's also got logic for dealing with
WrappedQuery instances.
b) the original reason why QueryUtils.makeQueryable was added (instead of
putting that logic in SolrQueryParser) was so that Solr plugins could use the
underlying lucene parser to parse user input (even if the resulting query
parsed to all negative clauses, or no clauses) and then programaticly
manipulate that query in a manner of their choosing -- calling makeQueryable if
that was the desire. The three useages Uwe describes would eliminate this
possibility (specificly bacause of "QP should simply parse to an empty BQ in
the case of only prohibited clauses." statement) ie: Perhaps i want to allow
my users to specify all MUST_NOT clauses, and then i want to add my *own* MUST
clause instead of a MatchAllDocsQuery.
...all of that said: i'm definitely in favor of more "signals" coming out of
the query parser of things that the caller should be aware of. particularly if
we can help deal with the situation of *nested* clauses that are semanticly
invalid (ie: "bar +(foo +(a the))"
> Move handling of query only containing MUST_NOT to QueryParser (and remove
> QueryUtils.makeQueryable() hack in Solr)
> -------------------------------------------------------------------------------------------------------------------
>
> Key: LUCENE-3460
> URL: https://issues.apache.org/jira/browse/LUCENE-3460
> Project: Lucene - Java
> Issue Type: Sub-task
> Components: core/queryparser
> Affects Versions: 3.4, 4.0
> Reporter: Uwe Schindler
> Assignee: Uwe Schindler
> Fix For: 4.0
>
>
> With the parent issue, users entering (a -b) into the queryparser can simply
> fail with an UnsupportedOperationException, if "a" is a stopword.
> Solr already has a hack to add a MatchAllDocsQuery, if a query only contains
> prohibited clauses.
> The other issue (not affecting prohibited clauses) with stopwords is: If the
> user enters (a the) into queryparser, the query will return no results, as
> "a" and "the" are stopwords. This confuses lots of people (not only
> developers, even ordinary users of our interfaces). If somebody queries for a
> stopword, the correct way to handle this is to return *all* documents
> (MatchAllDocsQuery).
> A possible solution, as suggested by Chris Male on IRC was: Add a flag to
> QueryParser to enable a "no-should-or-must-clauses" mode, where this is
> replaced by MatchAllDocs automatically. This would also solve the prohibited
> clause case, too.
> The stopword case is bad, but the opposite is as bad as returning all
> documents.
> At least this issue should somehow handle the only-prohibited case like Solr
> and remove the hack from Solr.
> Changing this in QueryParser is the more correct solution than doing this
> hidden in BQ.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
