[
https://issues.apache.org/jira/browse/LUCENE-6807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17065874#comment-17065874
]
Michał Torba commented on LUCENE-6807:
--------------------------------------
Bump. Why does toQueryString() method of a range query not produce a valid
range query?
> AbstractRangeQueryNode toQueryString not working as intended
> ------------------------------------------------------------
>
> Key: LUCENE-6807
> URL: https://issues.apache.org/jira/browse/LUCENE-6807
> Project: Lucene - Core
> Issue Type: Bug
> Components: core/queryparser
> Affects Versions: 5.3
> Reporter: Peter Barna
> Priority: Minor
> Attachments: LUCENE-6807-option1.patch, LUCENE-6807-option1.patch,
> LUCENE-6807-option2.patch, LUCENE-6807-option3.patch
>
> Original Estimate: 48h
> Remaining Estimate: 48h
>
> It is my understanding that for a given {{QueryNode}} node,
> {{parse(node.toQueryString());}} should return a {{QueryNode}} which is
> functionally identical to the original node.
> That is not the case with AbstractQueryNode:
> if we have a range query on FIELD from "A" to "B" ({{node = parse("FIELD:[A
> B]")}}), then {{node.toQueryString()}} will return "[FIELD:A FIELD:B]" which,
> in turn, is parsed as a range query on the default field from "FIELD:A" to
> "FIELD:B".
> As far as I know, this affects all versions of lucene.
> I believe I have the knowledge to provide the patch, so I will be working on
> that today.
> As of now, I have thought of two options to implement this fix, both of which
> involve modifying the {{ValueQueryNode}} interface to include a method which
> returns {{value}} as a {{CharSequence}}.
> The first option is to add a new method to the interface which returns
> (formatted if necessary) the value as a {{CharSequence}} and implement it in
> all implementing classes ({{FieldQueryNode}} and {{NumericQueryNode}}). Then
> in {{AbstractQueryNode#toQueryString()}} we will call that method and escape
> the values using the provided {{EscapeQuerySyntax}}.
> The second option is to make the protected method {{getTermEscaped()}}, which
> is already present in all implementing classes, public, and add it to the
> interface.
> While I think that the second option is certainly cleaner, I do not know why
> this method is protected in the first place, so I will proceed with the first
> option until someone who is more familiar with the lucene project than I am
> can comment on the matter.
> As I am writing this, it occurs to me that implementing the first option is
> essentially just bypassing the protected scope on {{getTermEscapeed()}}, so
> maybe it is correct to just review whether or not that method needs to be
> protected. It also occurred to me to use the existing {{getValue()}} method,
> and format and escape the {{toString()}} of that, but that depends on a
> generic class having implemented {{toString()}} in a way that plays nicely
> with the query parser, so, to me, this is below the two previously mentioned
> options.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
