[
https://issues.apache.org/jira/browse/LUCENE-3460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13114275#comment-13114275
]
Uwe Schindler commented on LUCENE-3460:
---------------------------------------
I also agree partly with Robert; with partly i mean: Returning nothing for
stop-words only confuses users, too, so we should do something.
Just to make it clear, this was on IRC:
{quote}
[15:11] chrismale: If someones query is all stopwords, then matching everything
makes sense.
[15:11] chrismale: every term got filtered out
[15:12] chrismale: Leaving you nothing
[15:12] chrismale: Nothing is parsed to MatchAllDocs
{quote}
So the issue description is *right* :-)
My idea was to add a setter to QP:
- the default is to work as it did before: To prevent the UOE, QP should simply
parse to an empty BQ in the case of only prohibited clauses. This would
preserve backwards compatibility for QP, it will never throw Exception
- add a "Solr" mode: This would add MatchAllDocsQuery with Occur.MUST, so this
would be identical behaviour like Solr does in QueryUtils. The special case in
Solr can be removed, QP never throws Exception.
- my favourite is this mode: If the user enters a query that only has
stop-words as positive clauses (we can easily detect this by counting terms),
the QP should throw a good ParseException explaining that the entered query
string does no produce a meaningful query, as all clauses *may* be stop words
(it could also be stripped of by other filters, not only stop filter - so the
message should be more generic). It would do this also if no negative queries
are involved. So a user entering "a the" would get a meaningfull explanation
that this is an invalid query.
> 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]
