lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sergiu gordea <>
Subject Re: QueryParser refactoring
Date Tue, 08 Mar 2005 13:54:42 GMT
Erik Hatcher wrote:

> On Mar 8, 2005, at 4:11 AM, sergiu gordea wrote:
>> In our project I save search strings, generated with query.toString 
>> in the database and I reconstruct the Query at runtime.
>> I would appreciate if the  new QueryParser will pass the following 
>> assert:
>> Query query = QueryParser.parse(queryString, analyzer);
>> Query query2 =  QueryParser.parse(query.toString(), analyzer);
>> assertEquals(query.toString(), query2.toString());
>> I think this might be a usefull test case ....
> I agree that this is a nice ideal, but it is unrealistic in the 
> general sense.  A custom analyzer could easily break this.  I suspect 
> there are other cases where this would break even with a plain 
> SimpleAnalyzer.
>     Erik

I understand that this is a feature that requires a lot of attention, 
but in my case it is a very usefull one.  Maybe the Query String that I 
save in the database will
help you understand how usefull it is for me. Of course, I use just 
StandardAnalyzer as a singleton in our project.
Anyway .. as I put the same analyzer in both classses, the test should pass.

So .. here is an example of how I parse a simple query string provided 
by a user ...

the user checks a few flags and writes "test ko AND NOT bo"
and the resulting query.toString() is saved in the database:

+(+(subject:test description:test keywordsTerms:test koProperties:test 
attachmentData:test) +(subject:ko description:ko keywordsTerms:ko 
koProperties:ko attachmentData:ko) -(subject:bo* description:bo* 
keywordsTerms:bo* koProperties:bo* attachmentData:bo*)) +creator:2 +skillLevel:0 
+(keywords:1000 keywords:1020)

I think you agree that is better to be saved in the database instead of  
creating a
CustomQuery class that implements Serializable and save it in the database.

Until now I haven't  had any problem to reconstruct the Query from the 
above string. I think this feature really gives value to Query class, 
and saves a lot development
time for many of  lucene users.
Maybe I'm pushing to much with this functionality ... but if I tell you 
that before i used BooleanQueries to build this query String, it was 
build up with
regular string concatenation, in method with more then  200 lines of 
code ...

  All the best,


> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message