> 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
