lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uwe Schindler (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (LUCENE-3460) Move handling of query only containing MUST_NOT to QueryParser (and remove QueryUtils.makeQueryable() hack in Solr)
Date Sun, 25 Sep 2011 14:00:26 GMT

     [ https://issues.apache.org/jira/browse/LUCENE-3460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Uwe Schindler updated LUCENE-3460:
----------------------------------

    Description: 
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.

  was:
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).

I propose to 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.

Changing this in QueryParser is the more correct solution than doing this hidden in BQ.


> 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message