I don't know much about the implementation details of the Query Parser. >From previous conversations on the list, I get the idea that allowing wildcards as >the first letter of a search introduces a large performance hit.
But I also think that this feature should be implemented by a search engine, so that it is easily accessible. Even if it is not programmatically difficult to manually build the query, most beginners are going to use the parser, and then ask the question why doesn't this work. The prospect of building the query manually will sound difficult, and may discourage them from using Lucene. So, if it can be implemented in such a way that you only take the performance hit when you put the wildcard as the first letter, I would like to see that implemented. If it causes a hit on all searches, then I think there should be more than one query parser available - and then users could choose themselves if they want to pay the performance price of more powerful parser. Just my thoughts as a user, Dan -----Original Message----- From: Brian Goetz [mailto:[EMAIL PROTECTED]] Sent: Wednesday, August 28, 2002 3:03 PM To: Lucene Developers List Subject: Re: [Bug 12137] New: - Can '*' or '?' symbol be used as the first character of a search? On Wed, Aug 28, 2002 at 07:52:01PM -0000, [EMAIL PROTECTED] wrote: > Do get me wrong, I did read the Parser Syntax, and understand that: > "Note: You cannot use a * or ? symbol as the first character of a search." > However, It would have been nice for this feature. I made the following > changes to QueryParser.jj, and it seems work fine. I am not sure if there is > any side effect though. Can someone verify this? I think this is a bad idea. First of all, the query parser is a CONVENIENCE, not the only way to build query objects. If the query parser language is too restrictive, then build the query objects programmatically. Its not that hard. There were reasons why the query language was designed this way. If you think that's an error, first you need to lobby for your position to change the design, THEN we can think about changing the parser. Parser are tricky. Small changes can have big, unexpected effects. Lets make sure we want to do this first (which I think we don't), and then we can look at the implementation. -- 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]>
