The "original" and "helper" aren't that descriptive to users.
It's named "helper" because it extends QueryParserHelper, that's the only reason. I think it's ok to rename "original" to something else. . I also share Mike's opinion, I prefer "default" over "original".
Mike - isn't "fast forwarding 3 years" means that the current QP will be removed, together w/ the OriginalQPHelper and we'll have just one QP?
OriginalQPHelper is not intended to be removed, it should be the new simple way to use the query parser. So, I agree with Mike, now is the best time to name it, while it's not released yet.
Mike - isn't "fast forwarding 3 years" means that the current QP will be removed, together w/ the OriginalQPHelper and we'll have just one QP? And I'd think we'll want to call it Default or something, so users can distinguish between it (which parses the Lucene query syntax) and another custom parser they wrote for their own syntax.
I agree that the current name is not too descriptive, but perhaps since it's just temporary it's not that bad? Add to that that 'Default' might be used after 3.0 to refer to the new QP which parses the Lucene syntax, and users will be confused w/ the 'Default' in 2.9 vs. the new one.
Maybe we can call it OldQPHelper, to encourage people to move faster to the new one?
ShaiOn Tue, Aug 4, 2009 at 2:47 AM, Luis Alves <firstname.lastname@example.org> wrote:
Michael McCandless wrote:Hi Mike,
OK thanks for the clarification... that makes sense. So the builder should really be a "rote" translation of a query node into the corresponding Query. All "interesting" work should instead be done by the processors (or maybe the parser).
Only the Processors should do "interesting" work, it is the only API that has access
to the QueryConfigHandler by design.
QueryConfigHandler - should hold all the information necessary to generate queries for the
specified index or system where it is being used. Example: field configuration, index configuration,
any other configuration that is useful to generate the queries.
SyntaxParser implementation should avoid doing "interesting" work, it should do the minimum
to create a syntax a tree that represents the user query and pass it to a QueryNodeProcessor
pipeline for the "interesting" work.