Hi, Another option for 1) is to use n-grams with token begin/end symbols. Then you won't need to use wildcards at all, but you'll have a larger index.
2) may be added to Lucene in the near future, actually, I saw a related JIRA issue. But in the mean time, yes, you coul dimplement it via a custom QParserPlugin. Otis -- Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch ----- Original Message ---- > From: "Vauthrin, Laurent" <laurent.vauth...@disney.com> > To: solr-user@lucene.apache.org > Sent: Monday, March 30, 2009 5:45:30 PM > Subject: Wildcard searches > > Hello again, > > I'm in the process of converting one of our services that was previously > using Lucene to use Solr instead. The main focus here is to preserve > backwards compatibility (even if some searches are not as efficient). > There are currently two scenarios that are giving me problems right now. > > 1. Leading wildcard searches/suffix searches (e.g. *ickey) > I've looked at https://issues.apache.org/jira/browse/SOLR-218. Is the > best approach to create a QParserPlugin and change the parser to allow > leading wildcards - setAllowLeadingWildcard(true)? At the moment we're > trying to avoid indexing terms in reverse order. > > 2. Phrase searches with wildcards (e.g. "Mickey Mou*") > From what I understand, Solr/Lucene doesn't support this but we used to > get results with the following code: > > new WildcardQuery(new Term("U_name", " Mickey Mou*")) > > Is it possible for me to allow this capability in a QParserPlugin? Is > there another way for me to do it? > > Thanks, > Laurent Vauthrin
