[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:40:58
Message-ID: 422EEEDA.6050405 () ifit ! uni-klu ! ac ! at
[Download RAW message or body]

Erik Hatcher wrote:

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

Unfortunately I don't have a lucene project on my computer as this 
moment and I cannot check myself,
do the tests for MultiFieldQueryParser also pass?

Best,

 Sergiu

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