From a philosophical point of view, I don't believe in making something really hard just because it may be bad. It may also be a requirement and may work out great for certain applications. Also, I believe in teaching people through documentation and support. I understand that a developer may try to solve a user's problem and set a parameter that may make things slow, but I also believe that most developers will read about it (at least to find out how to do it and what the different parameters mean). In this documentation can be a BIG DISCLAIMER teaching people about the potential for a really big hit. This may mean that the developer recommends a faster machine, or gives justification for why it may be slow.
What do other people think about this? This also bring up the idea of a Lucene properties file. I like the idea of having WildcardQuery have a definable limit of terms that it returns. --Peter On Thursday, August 29, 2002, at 07:07 PM, Brian Goetz wrote: > >> That's why I said it's a SMOP (small matter of programming). The >> rule that parses wildcards needs to check where the first wildcard in >> a term is, and if it's too near the front, throw an exception. Or >> something like that. > > Right. I wasn't suggesting it was hard, but I still think its not a > terribly good idea. Its just way too easy for some cowboy app > developer to say "why wouldn't I want this flexibility" (developers > _love_ flexibility) without fully understanding the implications, and > loose a DoS-waiting-to-happen on their user base. Some naive user > comes along, a year after this app developer who set the knob to zero > has left, and then management is left with the perception that "Lucene > is unstable." > > Now, in the past we talked about implementing a policy in the wildcard > query classes about "how wild" a query term could be, as an element of > database-wide policy. I think that questions of this sort belong in > the query classes, and not in the query parser anyway. But that > discussion petered out without any resolution. > > I'd be interested in reopening the "database-wide policy choices" > discussion, for things like this, default choice of tokenizer (so that > its harder to make the mistake of tokenizing with one analyzer and > searching with another), etc. > > > > -- > Brian Goetz > Quiotix Corporation > [EMAIL PROTECTED] Tel: 650-843-1300 Fax: > 650-324-8032 > > http://www.quiotix.com > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
