Query Refactoring: Moving parser NAME constant to corresponding query builder#11178
Conversation
|
As a further explanation: there were two cases where the 1:1 mapping from parsers to builders was not completely clear:
|
There was a problem hiding this comment.
in all the builders, you can remove the class name, just return NAME is enough.
|
good change! left a few comments |
127195f to
59305dc
Compare
|
I rebased this PR after recent changes on feature branch and addressed the two comments above. The two main changes here:
|
There was a problem hiding this comment.
I thought we discussed (missing bits in the review comments) to leave this as-is and to not introduce FQueryFilterBuilder as it is not needed. This change breaks bw compatibility as you pointed out, thus we should keep this class as-is, and if we do that it makes little sense to introduce a deprecated additional FQueryFilterBuilder. The idea is that two parsers sharing the same builder should not be a problem....unless I am missing something.
There was a problem hiding this comment.
All right, will remove FQueryFilterBuilder then, put the NAME of the extra FQueryFilterParser somewhere else in the QueryFilterBuilder then.
|
I did another review round, thanks @cbuescher |
|
@javanna I had another round, mostly reverting some of the changes in my prevoius commits. |
|
left a super minor comment on indentation, LGTM besides that |
… builder As part of the query refactoring, this PR moves the NAME field that currently identifies each query parser to the corresponding query builder. The reason for this, as discussed in elastic#11121 (comment), is that we need still need to be able to link parser and builder implementations, but that the query builder is independent of the parser (queries don't necessarily need to be coverted to XContent any more). Builders don't need to know about their parsers, but parsers need to be linked to their respective builders. Closes elastic#11178
f5a4e74 to
283fe90
Compare
…vename Query Refactoring: Moving parser NAME constant to corresponding query builder
… builder As part of the query refactoring, this PR moves the NAME field that currently identifies each query parser to the corresponding query builder. The reason for this, as discussed in elastic#11121 (comment), is that we need still need to be able to link parser and builder implementations, but that the query builder is independent of the parser (queries don't necessarily need to be coverted to XContent any more). Builders don't need to know about their parsers, but parsers need to be linked to their respective builders. Closes elastic#11178
…ring-movename Query Refactoring: Moving parser NAME constant to corresponding query builder
As part of the query refactoring, this PR moves the NAME field that currently identifies each query parser to the corresponding query builder. The reason for this, as discussed in #11121 (comment), is that we need still need to be able to link parser and builder implementations, but that the query builder is independent of the parser (queries don't necessarily need to be coverted to XContent any more). Builders don't need to know about their parsers, but parsers need to be linked to their respective builders.
This change does the following: