J.J. Larrea wrote: > I concur with your thoughts that there is room for such > utility classes, and that those would increase the use of > programmatic queries. I say this as a developer who also > "lazed out" and opted to simply construct a string and let > the QP do all the work (but who then had to subclass and > finally copy-and-modify QP to make it conform to requirements). > > The underlying issue may be that there are two quite > different concerns bundled into QueryParser: > - Parsing a string into a set of discrete query requests > - Constructing Query objects to meet those requests
Yeah - I agree. It seems that QueryParser has too many responsibilities. > If you take a look at > http://issues.apache.org/jira/browse/LUCENE-344 you'll see > that someone else (Matthew Denner) also had this belief, and > went so far as to implement a QueryFactory interface and a > couple of implementing classes. One has the construction > logic now found in QueryParser. Then there is a decorator > class which adds the functionality of MultiFieldQueryParser > and another which lower-cases terms. Thanks for the link - I'll certainly take a look at that patch. > Perhaps something along those lines that should be considered > for the next break in API continuity eg. Lucene 2.0. It > seems much cleaner than subclassing QP when all that is > needed is a variant in Query construction logic, and it also > provides a higher-level interface for constructing Query > objects (especially TermQuery) like you were proposing. > Unfortunately the actual LUCENE-344 patch appears out of date > with changes in QueryParser, MultiFieldQueryParser, etc. But > perhaps just the QueryFactory part would be a good starting > point for what you want to do. > > Anyway, just a thought. Many thanks for the ideas > - J.J. Dave This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
