On Mon, Dec 13, 2010 at 3:16 PM, Yonik Seeley <yo...@lucidimagination.com> wrote: > On Mon, Dec 13, 2010 at 3:07 PM, Robert Muir <rcm...@gmail.com> wrote: >> On Mon, Dec 13, 2010 at 3:04 PM, Yonik Seeley >> <yo...@lucidimagination.com> 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 consumption". 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: java-user-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org
