> you want what Lucene already does, but that's clearly not true Hmmm, let's pretend that "contents" field in my example wasn't analyzed at index time. The unstemmed form of terms will be indexed. But if I query with a stemmed form or use QueryParser with the SnowballAnalyzer, I'm not going to get a match. I could fix this situation by analyzing the indexed field at search time to match the query. I don't know that Lucene provides this opportunity and, as I said, maybe that's crazy.
> What do you mean when you say "rewriting" "Our current path to solving our problem requires additional fields which need rewritten". I meant actually altering the document in the index. My desire has been to write a new Query class implementation whereas you mentioned query rewriting (isn't that accomplished as in my example by passing an Analyzer to QueryParser?) > not discrete... limited number of prefixes So my document may have "myfield:A*foo*", "myfield:B*foo*", "myfield:A*dog*", and "myfield:D*cat*". Or, to phrase differently, "myfield:[PREFIX][PATTERN]" may appear any number of times where PREFIX comes from the set { A, B, C, D, E, ... }. This complexity is really a tangent of my question in order to avoid poor performance from WildcardQuery. ----- Original Message ---- From: Steven A Rowe <sar...@syr.edu> To: "java-user@lucene.apache.org" <java-user@lucene.apache.org> Sent: Fri, July 30, 2010 1:26:07 PM Subject: RE: InverseWildcardQuery Hi Justin, > > an example > > PerFieldAnalyzerWrapper analyzers = > new PerFieldAnalyzerWrapper(new KeywordAnalyzer()); > // myfield defaults to KeywordAnalyzer > analyzers.addAnalyzer("content", new SnowballAnalyzer(luceneVersion, >"English")); > // analyzers affects the indexed field value > IndexWriter writer = new IndexWriter(dir, analyzers, true, mfl); > // analyzers affects the parsed query string > QueryParser parser = new QueryParser(luceneVersion, "myfield", analyzers); > parser.setAllowLeadingWildcard(true); > Query query = parser.parse("*:* AND -myfield:\"*foo*\""); > // What about an Analyzer to match field value to the query at search time? > ScoreDoc[] docs = searcher.search(query, null, 1000).scoreDocs; I'm afraid that this "example" doesn't help me - my reading of "What about an Analyzer to match field value to the query at search time?" is that you want what Lucene already does, but that's clearly not true. > > An inverse query would require rewriting, too, I think. > > Why would implementing a new Query class requires document changes in the > index. Query rewriting is what I meant (and what I thought you meant). What do you mean when you say "rewriting" - how would it affect indexed documents? > > Can you turn those prefixes into field names > > No, the prefixes are not discrete. Multiple field values could start with > the same prefix. Hmm, again with the misunderstanding on my part - how is it that "prefixes are not discrete" and also "there are a limited number of prefixes ... (10ish)"? And why is it important that multiple field values could start with the same prefix? Why couldn't you just store all of those that share the same prefix in the field corresponding to the prefix? Steve --------------------------------------------------------------------- To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org