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

List:       lucene-user
Subject:    Re: QueryParser refactoring
From:       Erik Hatcher <erik () ehatchersolutions ! com>
Date:       2005-03-09 3:29:43
Message-ID: a8f4adcecee389f597ab08499fb79c80 () ehatchersolutions ! com
[Download RAW message or body]

On Mar 8, 2005, at 5:17 PM, 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.

That is a very reasonable mandate for QueryParser.  I agree.

I have committed a round of changes to the PrecedenceQueryParser.  I'm 
going to leave it alone for a while.  There are a couple of tests that 
are failing because I adjusted them to be as desired but not yet 
implemented.  Here are the short comings currently:

	assertQueryEquals("a OR !b", null, "a (-b)");
		junit.framework.AssertionFailedError: Query /a OR !b/ yielded /a -b/, 
expecting /a (-b)/

     query1 = parser.parse("A OR NOT B AND C");
     query2 = parser.parse("A (-B +C)");
     assertEquals(query1, query2);
		junit.framework.AssertionFailedError: expected:<field:A -(+field:B 
+field:C)> but was:<field:A (-field:B +field:C)>

I believe these are similar, if not identical, to what QueryParser does 
with queries, so we're no worse off and we now have operator precedence 
with AND/OR.  I feel the NOT/-/! precedence issue needs to be addressed 
before this is a viable replacement.  If any JavaCC savvy folks are 
interested in lending a handy to fix this remaining issue I'd be 
ecstatic!  I tried some things but thus far unsuccessful.

What else is missing/broken?

	Erik


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