You are right that starting to parse the query before the query component can get soon very ugly and complicated. You should take advantage of the flex parser, it is already in lucene contrib - but if you are interested in the better version, look at https://issues.apache.org/jira/browse/LUCENE-5014
The way you can solve this is: 1. use the standard syntax grammar (which allows *foo*) 2. add (or modify) WildcardQueryNodeProcessor to dis/allow that case, or raise error etc this way, you are changing semantics - but don't need to touch the syntax definition; of course, you may also change the grammar and allow only one instance of wildcard (or some combination) but for that you should probably use LUCENE-5014 roman On Mon, May 27, 2013 at 2:18 PM, Isaac Hebsh <isaac.he...@gmail.com> wrote: > Hi. > > Searching terms with wildcard in their start, is solved with > ReversedWildcardFilterFactory. But, what about terms with wildcard in both > start AND end? > > This query is heavy, and I want to disallow such queries from my users. > > I'm looking for a way to cause these queries to fail. > I guess there is no built-in support for my need, so it is OK to write a > new solution. > > My current plan is to create a search component (which will run before > QueryComponent). It should analyze the query string, and to drop the query > if "too heavy" wildcard are found. > > Another option is to create a query parser, which wraps the current > (specified or default) qparser, and does the same work as above. > > These two options require an analysis of the query text, which might be an > ugly work (just think about nested queries [using _query_], OR even a lot > of more basic scenarios like quoted terms, etc.) > > Am I missing a simple and clean way to do this? > What would you do? > > P.S. if no simple solution exists, timeAllowed limit is the best > work-around I could think about. Any other suggestions? >
