[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-08 13:54:42
Message-ID: 422DAEA2.4080200 () ifit ! uni-klu ! ac ! at
[Download RAW message or body]

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 
+classType:package.share.om.knowledgeobject +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,

 Sergiu
 

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