lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael McCandless <luc...@mikemccandless.com>
Subject Re: Range queries get misinterpreted when parsed twice via the "Standard" parsers
Date Fri, 10 Mar 2017 10:34:04 GMT
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 <quux00@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 <trejkaz@trypticon.org> wrote:
>
> > On Fri, 10 Mar 2017 at 01:19, Erick Erickson <erickerickson@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
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message