lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik Hatcher <e...@ehatchersolutions.com>
Subject Re: Query.toString refactoring
Date Thu, 09 Dec 2004 17:33:20 GMT
On Dec 9, 2004, at 8:34 AM, Erik Hatcher wrote:
> First let me demonstrate an issue.  I'm currently using QueryParser 
> with AND as the default operator for one type of user query.  For 
> another type of user query I create an OR'd BooleanQuery 
> programatically.
>
> I want all queries, regardless of how they were created, to be 
> converted back into a parsable expression resulting in the same Query 
> when parsed again (ignoring any analyzer issues at this point).  For a 
> programmatically created BooleanQuery for "term1 OR term2", the 
> toString method returns:
>
> 	term1 term2
>
> This, of course, when parsed again using AND as the default operator, 
> completely changes the query.
>
> My first proposal is to change BooleanQuery.toString() to always put " 
> OR " between terms that are not required or prohibited.  Any 
> objections to this change?

I quickly created a QueryConverter class this morning in my own 
codebase that essentially emulates BooleanQuery.toString, with this 
additional else ...

     for (int i = 0; i < clauses.length; i++) {
       BooleanClause c = clauses[i];
       if (c.isProhibited())
         buffer.append("-");
       else if (c.isRequired())
         buffer.append("+");
       else {
         if (i != 0 && i != clauses.length) {
           // a middle clause
           buffer.append("OR ");
         }
       }

This solved the issue of BooleanQuery -> toString -> QueryParser (with 
AND as default operator) producing a different query for the cases I've 
tried.  There may be some edge cases where this won't work properly.  
Let me know if you can think of any cases where this would not work.

I still would like to have a pluggable facility to allow custom query 
parsers to provide their own conversion of a Query to its syntax.  
Should we pursue this idea as something generalizable?  Or should this 
be done on a custom basis?

Thanks,
	Erik


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


Mime
View raw message