apache / apache/lucene

QueryNode#toQueryString says it produces a string in the syntax understood by "the query parser", but cannot possibly know how [LUCENE-7616]

Open
#8,667 1 comment 0 reactions 0 assignees View on GitHub
affects-version:6.3 legacy-jira-priority:Major module:queryparser type:bug
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.