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. On Mon, Aug 3, 2009 at 8:18 PM, Shai Erera <ser...@gmail.com> wrote: > 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? > > Shai > > > On Tue, Aug 4, 2009 at 2:47 AM, Luis Alves <lafa...@gmail.com> wrote: > >> Michael McCandless wrote: >> >> >> 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). >> >> >> Hi Mike, >> >> 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. >> >> -- >> -Lafa >> >> >> >
