OK I will open an issue to further iterate on this... Mike
On Tue, Aug 4, 2009 at 1:34 AM, Adriano Crestani<adrianocrest...@gmail.com> wrote: > 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 >>> >> > > --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
