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

List:       lucene-user
Subject:    Re: QueryParser refactoring
From:       sergiu gordea <gsergiu () ifit ! uni-klu ! ac ! at>
Date:       2005-03-09 12:38:00
Message-ID: 422EEE28.2020509 () ifit ! uni-klu ! ac ! at
[Download RAW message or body]

Chris Hostetter wrote:

>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"
>  
>
I makes sense, but I think that invalid queries should trow an 
exception, at least at search time.

>: 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.
>  
>
silently drop clauses I consider to be the worst solution ... because 
the user will be confused... it will be hard to discover
why the search is not working how it espects to. An alternative will be 
to use Log4J to log these warnings....

 

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


---------------------------------------------------------------------
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]