Hello all!
We discovered an issue while testing, where some infrequent queries would
return really strange results.
We use a client-side formula to auto generate boost queries for some fields
based on some external weights. It turns out that these external weights,
if really small, they might take the form of exponential decimals eg.
foo:bar^2.77E-4.
Apparently the lucene query parser does not support the exponential
notation (which is fine, we changed our client code). The main issue is
that it will not alert the client for malformed input eg. throw an
exception in such a case, but will continue with parsing the rest of the
number. For the example above, it will silently convert a query of
foo:bar^2.77E-4 to a boolean query of foo:bar^2.77 field:E-4.
Not sure if that has been brought up before. I guess that could be resolved
on the grammar level by eg. requiring a whitespace after the boost number
(and possibly support the exponent format :) Should we file a ticket for
this?
Thanks!
Spyros
We discovered an issue while testing, where some infrequent queries would
return really strange results.
We use a client-side formula to auto generate boost queries for some fields
based on some external weights. It turns out that these external weights,
if really small, they might take the form of exponential decimals eg.
foo:bar^2.77E-4.
Apparently the lucene query parser does not support the exponential
notation (which is fine, we changed our client code). The main issue is
that it will not alert the client for malformed input eg. throw an
exception in such a case, but will continue with parsing the rest of the
number. For the example above, it will silently convert a query of
foo:bar^2.77E-4 to a boolean query of foo:bar^2.77 field:E-4.
Not sure if that has been brought up before. I guess that could be resolved
on the grammar level by eg. requiring a whitespace after the boost number
(and possibly support the exponent format :) Should we file a ticket for
this?
Thanks!
Spyros