Why don't we fix this in Lucene? It sounds like your fix (overriding toQueryString for the range query nodes) is contained? Could you open an issue and add a patch?
I agree it's silly to produce [ts:X ts:Y] syntax. Mike McCandless http://blog.mikemccandless.com On Thu, Mar 9, 2017 at 8:59 PM, Michael Peterson <quu...@gmail.com> wrote: > 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 > > >
