lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Muir <>
Subject Re: The logic of QueryParser
Date Mon, 13 Dec 2010 20:27:11 GMT
On Mon, Dec 13, 2010 at 3:16 PM, Yonik Seeley
<> wrote:
> On Mon, Dec 13, 2010 at 3:07 PM, Robert Muir <> wrote:
>> On Mon, Dec 13, 2010 at 3:04 PM, Yonik Seeley
>> <> wrote:
>>> I think of the Lucene QueryParser like SQL. SQL is text based and also
>>> meant for human entered text - but for either very expert users, or
>>> programmatically created queries.  You normally don't want to pass
>>> text from a search box directly to an SQL database or to the Lucene
>>> QueryParser.
>> Then why does solr use it by default?
> Because it's a decent default?  It was also the only choice when Solr
> was first created.  I don't see a compelling reason to change that.

Right, for the same reason its a good way for a lot of lucene apps to
get started quickly.

> Solr fits about the same place a database does in many applications...
> it's certainly not meant for users to query directly.  There's
> normally a web application that handles interaction with the user and
> creates/submits queries to Solr.

Sure, but just because Solr "fits the same place as a database" for
some apps doesn't suddenly make the queryparser "not for human

There's definitely some human-oriented stuff in there that I'm not a
huge fan of (believe it or not, the whole way that its localized for
one), but that doesn't mean it should be treated like SQL. For lots of
apps it works just fine as a start.

And this is even more the reason to have the default as a coordinated
OR query, it works ok for both short and long queries, for both
synthetic languages where AND seems like it would make sense, and for
more analytic languages where AND as a default is completely stupid.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message