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 > > >
