[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:25:23
Message-ID: 422EEB33.8090809 () ifit ! uni-klu ! ac ! at
[Download RAW message or body]

Doug Cutting wrote:

> sergiu gordea wrote:
>
>> 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.
>
>
> Your application will be more robust if you instead stored the checked 
> flags and "test ko AND NOT bo" in the database and then re-generate 
> the Lucene query as needed.

> For example, if you wanted to add an "author" field that was searched 
> by default, then all of the queries in your database would be 
> invalid.  Also, more to the point, if Query.toString() changes, the 
> semantics of your queries might change, or if the QueryParser changes 
> they might even become unparsable.

You are right ...  The problem is that the generated String is used in 
extended search functionality, which is quite often improved. Storing
the  "test ko AND NOT bo" string is not enough to regenerate the query, 
because all the other components of the query depend on user data.
Yes, it is better to store 2 Strings  in the database "test ko AND NOT 
bo" and  "+creator:2 +classType:package.share.om.knowledgeobject 
+skillLevel:0 +(keywords:1000 keywords:1020)"
in the database, and then I'll be able to reconstrunct the query at runtime.

I chose to Store the query.toString() because the parsing of this string 
required to write just one line of code  and it was working perfectly 
(one line of code means also less maintainance effort).

I'm not a very experenced software developer (I'm still young :)) ), but 
I've already  meet some sitautions when I needed to make reversible some 
transformations to be reversible
(I mean something like Query => String => Query, with the constraint 
initial query equals final query).

Ok ... I give up ... if  this feature is to hard to be implemented, the 
soltution will be to work around in my source code to make it work.


>
> The general rule is that the QueryParser should only be used to 
> directly parse user input.  Programs should not generate strings to 
> pass to QueryParser.  Query.toString() is a program-generated string.  
> If you must save a query, save the user's input.

You are right, but I already explained why it was much more easy to 
store the generated query String.
And .. there are also some other things to consider. What I explained 
here is the implementation of the "Saved Search" concept .
The search must return the documents that were found first time + new 
added documents, even if the structure of the index is changed....

This is my problem, not lucene's, I just wanted to show you how useful 
is for me the fact that the Query => String transformation is reversible.
Of course there are alternativa solutions all the time.

 Best,

 Sergiu

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