Everyone - thanks for the feedback. Trejkaz,
I agree. The [ts:X ts:Y] range syntax seems odd at best and broken at worst. If the field name for the range has to be the same for both the lower and upper bound why put it there twice inside the braces? In addition, a user cannot type that syntax and have it work, so why use it at all, even "internally"? In any case, the solution we settled on was to override the toQueryString method for the various RangeQueryNode implementations in a QueryNodeProcessorImpl class that will spit out the "classic" range syntax, ts:[X TO Y]. That works great, but it seems odd to require users of Lucene to have to implement that. I would think it could/should be built-in either to the existing RangeQueryNodes or have a standard QueryNodeProcessorImpl in Lucene that does this translation for users that need to do query tree modification. Feedback welcome if I'm missing something. -Michael On Thu, Mar 9, 2017 at 7:06 PM, Trejkaz <trej...@trypticon.org> wrote: > On Fri, 10 Mar 2017 at 01:19, Erick Erickson <erickerick...@gmail.com> > wrote: > > > There has never been a guarantee that going back and forth between a > > parsed query and its string representation is idempotent. so this > > isn't supported. > > > Maybe delete the toQueryString method... > > There is a fundamental design problem with it anyway, in that it produces a > syntax which isn't necessarily the one you parsed in the first place. We > ended up making a whole family of QuerySyntaxFormatter for all node classes > and had it produce exactly the syntax we consider the cleanest. (Still not > what the user typed in, but aiming to be better when the two differ.) > > Although in this case, it does seem like it could have moved the field > outside the brackets to avoid this problem... > > TX >
