lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Murray Altheim <m.alth...@open.ac.uk>
Subject Re: Query.toString refactoring
Date Thu, 09 Dec 2004 13:44:40 GMT
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 (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.

For myself, I can see both a requirement to be able to maintain the
original query and a canonical version. But mixing them seems like
it might cause problems.

> 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).

Murray

......................................................................
Murray Altheim                    http://kmi.open.ac.uk/people/murray/
Knowledge Media Institute
The Open University, Milton Keynes, Bucks, MK7 6AA, UK               .

  Life as a modern man is dangerous:

     "Laptops can reach internal operating temperatures of over
      70C.  They are frequently positioned close to the scrotum,
      as well as being capable of producing direct local heat,
      they require the user to sit with his thighs close together
      to balance the machine, trapping the scrotum."
      http://www.guardian.co.uk/online/news/0,12597,1369644,00.html

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