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