QueryNode#toQueryString says it produces a string in the syntax understood by "the query parser", but cannot possibly know how [LUCENE-7616]
- Dominant language
- Java
- Stars
- 3.6k
- Forks
- 1.4k
- Avg merge
- 2d 11h
- Merged PRs (30d)
- 88
Description
(Not an implementation "bug" so much as a design error, but working within the confines of JIRA here.)
The "flexible" query parser framework allows custom query syntaxes to be implemented on top of the existing query node, processor and builder classes.
Now, QueryNode has a toQueryString method which ostensibly converts the node back into a string appropriate for passing back through the parser. However, in practice, this method is implemented to return a syntax only appropriate for passing back to StandardQueryParser, **not** the parser you got the node from. The node itself has no idea what parser it came from, so it makes sense that this method could never work as currently designed.
I don't really know what the right way to fix this is.
Option A: Make QueryNode aware of which parser it came from, and add methods into the parser to format queries back into a string, so that this method can be implemented correctly. Sounds fine, except programmatically creating QueryNode objects directly becomes a hassle.
Option B: Deprecate toQueryString and introduce a new SyntaxFormatter interface which converts QueryNode to CharSequence and provide an appropriate implementation for each existing SyntaxParser. Seems sensible and the most flexible option, but requires a lot of tiny classes to be implemented.
Are there any other options?
---
Migrated from [LUCENE-7616](https://issues.apache.org/jira/browse/LUCENE-7616) by Trejkaz
Contributor guide
Research direction
Start by tracing QueryNode#toQueryString and how StandardQueryParser uses QueryNode, then compare that with the flexible query parser's processors and builders. Review the proposed parser-aware and SyntaxFormatter approaches; done requires an agreed design that can format nodes for the parser that produced them.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- search
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100