lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik Hatcher <>
Subject Re: Query.toString refactoring
Date Thu, 09 Dec 2004 14:33:47 GMT
On Dec 9, 2004, at 8:44 AM, Murray Altheim wrote:
> 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?
> Erik,
> You seem to be describing two different things, one a user-entered
> style and another a "canonical" style. Could we perhaps keep the
> current toString() and add a separate method such as 
> toCanonicalString()
> or something akin? It seems that (a) altering something so fundamental
> may have unintended consequences across the installed base, and

Altering the toString output certainly has backwards compatible issues, 
and thus I'd really only effect this type of change for 1.9/2.0 
codebase.  However, if done properly, it would be more of a fix cause 
additional issues.  The toString method has always been noted as being 
basically for information purposes anyway, and not guaranteed to be 
QueryParser-compliant, though for the most part it is.

>  (b)
> there may be both added benefits and unintended problems with adding
> ORs where they didn't exist that could be shaken out over a longer
> period of time.

Could you elaborate on where there may be problems with putting an OR 
in?  It certainly is not entirely trivial to do this, as it relies on 
only putting an OR between terms.

>> My second proposal, and this relates to a custom query parser I'm 
>> working on, is to separate the conversion of a Query to a String 
>> completely from the Query class itself.  I envision some type of 
>> abstract factory mechanism, with the default implementation being the 
>> existing (mostly QueryParser compatible) format.  Query.toString() 
>> would delegate to the formatter factory.  The formatting 
>> implementation would be pluggable to allow other custom query 
>> expression formats to be generated from any Query instance.
>> I haven't fleshed out the exact design yet - I'm soliciting ideas for 
>> this effort.  Thoughts?
> Not any detailed ones, as I'm rushing out the door in a minute, but
> I agree with the formatter idea and think it is a better solution
> than altering the toString() method (if I understand both proposals
> correctly).

Either way the toString method will be altered, unless we decide on an 
alternate approach of an external facility that can take a general 
Query and output, in a pluggable way, a parsable String.  Doing it 
externally, though, requires that a Query expose its inner workings 
publicly, whereas an internal to Query hook allows a Query itself to 
provide these inner details.

Actually talking it out, it does seem a completely external facility 
makes sense, requiring Query's that want to participate appropriately 
to expose their information publicly.


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

View raw message