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.
Erik
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
