[prev in list] [next in list] [prev in thread] [next in thread] 

List:       lucene-user
Subject:    Re: QueryParser refactoring
From:       Chris Hostetter <hossman_lucene () fucit ! org>
Date:       2005-03-08 22:17:38
Message-ID: Pine.LNX.4.58.0503081405430.21891 () hal ! rescomp ! berkeley ! edu
[Download RAW message or body]


Earlier in this thread...

: >>> +a -> a
: >>
: >> Hmmm.... this is a debatable one.  It's returning a TermQuery in this
: >> case for "a".  Is that appropriate?  Or should it return a
: >> BooleanQuery
: >> with a single TermQuery as required?

: > Ok.
: > The question how to handle BooleanQueries, that contain prohibited
: > terms
: > only, is a question on it's own.
: > In my fix I choose to silently drop these queries. Basically because
: > it's
: > effectivly dropped during querying anyway.

...I would argue that the most correct behavior would be for QP to
generate a Boolean query indicating the required/expluded term -- even if
a Searcher can't run that query as is.  It's not the QueryParsers job to
know what Query object structures make sense or not, just to know what the
sanest possible maping from text to query object tree is.

i can think of some very valid use cases where a client would build a
complex Query out of some progromaticly generated Query objects, and the
Query returned by the QP -- those clients aren't going to be happy if QP
is returning an exception because the Query it's generating doesn't look
"valid"

(consider the simple case of an author pulldown, and a text box.  i may
want to build up a query object based on the construction of a Term query
from my pulldown, and the results of parsing the text box -- in which case
having QP return a BooleanQuery with one clause is perfectly valid and
ideal for me, becuase it let's people say "+author:foo +text" or
"+author:foo -text")

: > Is this what we want to happen for a general purpose next generation
: > Lucene QueryParser though?  I'm not sure.  Perhaps this should be a
: > ParseException instead?

: That's ok then. Throw a ParseException and whoever doesn't like that,
: can overwrite the method and either keep the query (knowing that it will
: be ignored in search anyway) or drop it.

if that's the route people want to go, then i'd like to instead advocate
that the default behavior for this situation be no error.



-Hoss


---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org

[prev in list] [next in list] [prev in thread] [next in thread]