lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Doug Cutting <cutt...@apache.org>
Subject Re: QueryParser refactoring
Date Tue, 08 Mar 2005 17:20:23 GMT
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.

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.

Doug

---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org


Mime
View raw message