I think that the only difference we have is that you see the Query Parser as a convenience for the app users, while I see it as a convenience to the app users and the app developers. Its probably a good thing to ship lucene with the query parser that doesn't allow you to do the search that makes an expensive hit. However, it seems to lead to a bug report every few weeks....
For those of us app developers that need to support a wild card query that can have the wild cards anywhere, I (as a lazy app developer) would like to be able to plug in a different query parser (that has at least been checked by and is hopefully supported as a part of lucene by those that know the lucene internals for validity) and will hopefully be aware that this parser will have worse performance on queries that have leading wildcards because I was warned when I downloaded it, or something along those lines. Then I as a developer will take measures as appropriate to make sure the users don't create a DOS attack on my system if this performance hit is significant on my index. I understand that this probably makes you cringe, however as a lucene developer, since now you would have 2 parsers to support. Given the number of times the question is asked, something probably should be changed... but I don't know which solution that has been given so far should be used (if any) since they all have significant downsides. As an app developer, I would have to lean toward "make it easy for me - aka make the query parser do the work". But these are all just my thoughts, and I don't actually have to write the query parser, so its easy for me to say. Dan ***************************** Daniel C. Armbrust Medical Informatics Research Information Services Mayo Clinic Rochester ***************************** -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
