You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@lucene.apache.org by Justin <cr...@yahoo.com> on 2010/07/30 16:29:36 UTC
InverseWildcardQuery
Any hints on making something like an InverseWildcardQuery?
We're trying to find all documents that have at least one field that doesn't
match the wildcard query.
Or is there a way to inverse any particular query?
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
Re: InverseWildcardQuery
Posted by Justin <cr...@yahoo.com>.
> make both a stemmed field and an unstemmed field
While this approach is easy and would work, it means increasing the size of the
index and reindexing every document. However, the information is already
available in the existing field and runtime analysis is certainly faster than
more disk I/O.
> Changing the index at query time
No... I'm sure I left out enough details to be confusing. The additional fields
in our current workaround need to be managed periodically over the course of a
document's lifetime, not at query time. To be honest, I'm not involved on the
workaround. I'm just trying to avoid going down the wrong path.
> Query.html#rewrite
So it sounds like I should attempt to write my own InverseWildcardQuery class
which overrides this method. Perhaps I can use WildcardQuery as an example?
WildcardQuery has changed parent classes over recent versions and and we're
unfortunately using the older at the moment.
I guess I had hoped others have handled this type of query before. Again, we're
just trying to find all documents that have at least one field that doesn't
match the wildcard query.
----- Original Message ----
From: Steven A Rowe <sa...@syr.edu>
To: "java-user@lucene.apache.org" <ja...@lucene.apache.org>
Sent: Fri, July 30, 2010 3:01:14 PM
Subject: RE: InverseWildcardQuery
> > 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.
I don't know of any facility in Lucene to re-analyze indexed content at search
time. This is an IR anti-pattern - it defeats the purpose of constructing the
inverted index.
People generally decide prior to indexing what kind of queries they need to
support, and then perform all required document analysis at index time. To use
your stemming example, if you need to be able to match against both stemmed and
unstemmed forms, you would make both a stemmed field and an unstemmed field, and
then construct corresponding sub-queries against each as required.
> > 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?)
Changing the index at query time, unless you have a tiny set of documents,
sounds like a big mistake to me. Again, extremely expensive.
Query rewriting:
<http://lucene.apache.org/java/3_0_2/api/all/org/apache/lucene/search/Query.html#rewrite%28org.apache.lucene.index.IndexReader%29>
> > 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.
I still think you could make one field for each PREFIX, and then do whatever
query you want on each of those fields.
If you need to support "contains" functionality (e.g. "A:*foo*"), you might want
to look into ngram analysis at indexing time (and maybe also at query time,
depending on the source of your queries):
<http://lucene.apache.org/java/3_0_2/api/all/org/apache/lucene/analysis/ngram/NGramTokenFilter.html>
You would have to know the minimum and maximum length of the contained string
you would want to query for.
Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
RE: InverseWildcardQuery
Posted by Steven A Rowe <sa...@syr.edu>.
> > 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.
I don't know of any facility in Lucene to re-analyze indexed content at search time. This is an IR anti-pattern - it defeats the purpose of constructing the inverted index.
People generally decide prior to indexing what kind of queries they need to support, and then perform all required document analysis at index time. To use your stemming example, if you need to be able to match against both stemmed and unstemmed forms, you would make both a stemmed field and an unstemmed field, and then construct corresponding sub-queries against each as required.
> > 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?)
Changing the index at query time, unless you have a tiny set of documents, sounds like a big mistake to me. Again, extremely expensive.
Query rewriting: <http://lucene.apache.org/java/3_0_2/api/all/org/apache/lucene/search/Query.html#rewrite%28org.apache.lucene.index.IndexReader%29>
> > 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.
I still think you could make one field for each PREFIX, and then do whatever query you want on each of those fields.
If you need to support "contains" functionality (e.g. "A:*foo*"), you might want to look into ngram analysis at indexing time (and maybe also at query time, depending on the source of your queries):
<http://lucene.apache.org/java/3_0_2/api/all/org/apache/lucene/analysis/ngram/NGramTokenFilter.html>
You would have to know the minimum and maximum length of the contained string you would want to query for.
Steve
Re: InverseWildcardQuery
Posted by Justin <cr...@yahoo.com>.
> 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 <sa...@syr.edu>
To: "java-user@lucene.apache.org" <ja...@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-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
RE: InverseWildcardQuery
Posted by Steven A Rowe <sa...@syr.edu>.
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
Re: InverseWildcardQuery
Posted by Justin <cr...@yahoo.com>.
> 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;
> An inverse query would require rewriting, too, I think.
Why would implementing a new Query class requires document changes in the index.
> Can you turn those prefixes into field names
No, the prefixes are not discrete. Multiple field values could start with the
same prefix.
Writing something like InverseWildcardQuery seems like the most appropriate
solution. My thought to have another Analyzer used on the field value at search
time may be crazy, I don't know.
----- Original Message ----
From: Steven A Rowe <sa...@syr.edu>
To: "java-user@lucene.apache.org" <ja...@lucene.apache.org>
Sent: Fri, July 30, 2010 12:04:58 PM
Subject: RE: InverseWildcardQuery
Hi Justin,
> Unfortunately the suffix requires a wildcard as well in our case. There
> are a limited number of prefixes though (10ish), so perhaps we could
> combine them all into one query. We'd still need some sort of
> InverseWildcardQuery implementation.
>
> > use another analyzer so you don't need wildcards
>
> I know analyzers can be used with IndexWriter and with QueryParser. Is
> there somewhere an analyzer could be used to alter the field to match the
> query at search time instead of altering the query to match the field?
Can you give an example of what you mean?
> Our current path to solving our problem requires additional fields which
> need rewritten causing a much larger performance degredation. One of the
> two paths above would be much more desirable.
An inverse query would require rewriting, too, I think.
You say you have 10-ish prefixes. Can you turn those prefixes into field names,
and index a token like EMPTY when there are no values for a particular prefix?
Then your query would be (F1:EMPTY OR F2:EMPTY ... OR F10:EMPTY).
Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
RE: InverseWildcardQuery
Posted by Steven A Rowe <sa...@syr.edu>.
Hi Justin,
> Unfortunately the suffix requires a wildcard as well in our case. There
> are a limited number of prefixes though (10ish), so perhaps we could
> combine them all into one query. We'd still need some sort of
> InverseWildcardQuery implementation.
>
> > use another analyzer so you don't need wildcards
>
> I know analyzers can be used with IndexWriter and with QueryParser. Is
> there somewhere an analyzer could be used to alter the field to match the
> query at search time instead of altering the query to match the field?
Can you give an example of what you mean?
> Our current path to solving our problem requires additional fields which
> need rewritten causing a much larger performance degredation. One of the
> two paths above would be much more desirable.
An inverse query would require rewriting, too, I think.
You say you have 10-ish prefixes. Can you turn those prefixes into field names, and index a token like EMPTY when there are no values for a particular prefix? Then your query would be (F1:EMPTY OR F2:EMPTY ... OR F10:EMPTY).
Steve
Re: InverseWildcardQuery
Posted by Justin <cr...@yahoo.com>.
> indexing your terms in reverse
Unfortunately the suffix requires a wildcard as well in our case. There are a
limited number of prefixes though (10ish), so perhaps we could combine them all
into one query. We'd still need some sort of InverseWildcardQuery
implementation.
> use another analyzer so you don't need wildcards
I know analyzers can be used with IndexWriter and with QueryParser. Is there
somewhere an analyzer could be used to alter the field to match the query at
search time instead of altering the query to match the field?
Our current path to solving our problem requires additional fields which need
rewritten causing a much larger performance degredation. One of the two paths
above would be much more desirable.
----- Original Message ----
From: Uwe Schindler <uw...@thetaphi.de>
To: java-user@lucene.apache.org
Sent: Fri, July 30, 2010 10:41:13 AM
Subject: RE: InverseWildcardQuery
With all these requirements you slow down your queries immense. You should
think about indexing your terms different:
- if you need leading wildcards, think about indexing your terms in reverse!
Wildcards starting with * needs to iterate all terms, so it's very slow (and
because of this defaults to be disabled)
- wildcards and regexes should always be used sparingly, as it can happen
that the whole term dictionary needs to be checked. Maybe you should use
another analyzer, so you don't need wildcards.
Uwe
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: uwe@thetaphi.de
> -----Original Message-----
> From: Ian Lea [mailto:ian.lea@gmail.com]
> Sent: Friday, July 30, 2010 5:33 PM
> To: java-user@lucene.apache.org
> Subject: Re: InverseWildcardQuery
>
> > I think you're suggesting, for example, "*:* AND -myfield:foo*".
>
> Yes, I think that is equivalent.
>
> > If my document contains "myfield:foobar" and "myfield:dog", the
> > document would be thrown out because of the first field. I want to
> > keep the document because the second field does not match.
>
> OK, too hard for me ...
>
> > Related, is there a way to use wildcards to match the beginning of the
> field?
> >
> > org.apache.lucene.queryParser.ParseException: Cannot parse '*:* AND
> > -myfield:*foo*': '*' or '?' not allowed as first character in
> > WildcardQuery
>
> Yes. QueryParser.setAllowLeadingWildcard().
>
>
> --
> Ian.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-user-help@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
RE: InverseWildcardQuery
Posted by Uwe Schindler <uw...@thetaphi.de>.
With all these requirements you slow down your queries immense. You should
think about indexing your terms different:
- if you need leading wildcards, think about indexing your terms in reverse!
Wildcards starting with * needs to iterate all terms, so it's very slow (and
because of this defaults to be disabled)
- wildcards and regexes should always be used sparingly, as it can happen
that the whole term dictionary needs to be checked. Maybe you should use
another analyzer, so you don't need wildcards.
Uwe
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: uwe@thetaphi.de
> -----Original Message-----
> From: Ian Lea [mailto:ian.lea@gmail.com]
> Sent: Friday, July 30, 2010 5:33 PM
> To: java-user@lucene.apache.org
> Subject: Re: InverseWildcardQuery
>
> > I think you're suggesting, for example, "*:* AND -myfield:foo*".
>
> Yes, I think that is equivalent.
>
> > If my document contains "myfield:foobar" and "myfield:dog", the
> > document would be thrown out because of the first field. I want to
> > keep the document because the second field does not match.
>
> OK, too hard for me ...
>
> > Related, is there a way to use wildcards to match the beginning of the
> field?
> >
> > org.apache.lucene.queryParser.ParseException: Cannot parse '*:* AND
> > -myfield:*foo*': '*' or '?' not allowed as first character in
> > WildcardQuery
>
> Yes. QueryParser.setAllowLeadingWildcard().
>
>
> --
> Ian.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-user-help@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
Re: InverseWildcardQuery
Posted by Ian Lea <ia...@gmail.com>.
> I think you're suggesting, for example, "*:* AND -myfield:foo*".
Yes, I think that is equivalent.
> If my document contains "myfield:foobar" and "myfield:dog", the document would
> be thrown out because of the first field. I want to keep the document because
> the second field does not match.
OK, too hard for me ...
> Related, is there a way to use wildcards to match the beginning of the field?
>
> org.apache.lucene.queryParser.ParseException: Cannot parse '*:* AND
> -myfield:*foo*': '*' or '?' not allowed as first character in WildcardQuery
Yes. QueryParser.setAllowLeadingWildcard().
--
Ian.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
Re: InverseWildcardQuery
Posted by Justin <cr...@yahoo.com>.
> assuming that you mistakenly used the same field name
Nope, wasn't a mistake. We'd have to dynamically iterate through an unknown
number of fields if we didn't use the same one.
----- Original Message ----
From: Steven A Rowe <sa...@syr.edu>
To: "java-user@lucene.apache.org" <ja...@lucene.apache.org>
Sent: Fri, July 30, 2010 11:14:17 AM
Subject: RE: InverseWildcardQuery
Hi Justin,
> [...] "*:* AND -myfield:foo*".
>
> If my document contains "myfield:foobar" and "myfield:dog", the document
> would be thrown out because of the first field. I want to keep the
> document because the second field does not match.
I'm assuming that you mistakenly used the same field name above in
("myfield:foobar" and "myfield:dog"), and that you instead meant:
"myfield1:foobar" and "myfield2:dog".
I think you can get what you want by specifying every field in the query - e.g.,
if each document has the same set of two fields F1 and F2:
(*:* AND -F1:foo*) OR (*:* AND -F2:foo*)
Truth table for four documents:
Doc1: F1:foobar (no-match), F2:dog (match) => match
Doc2: F1:cat (match), F2:dog (match) => match
Doc3: F1:cat (match), F2:foosball (no-match) => match
Doc4: F1:foobar (no-match), F2:foosball (no-match) => no-match
Good luck,
Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
RE: InverseWildcardQuery
Posted by Steven A Rowe <sa...@syr.edu>.
Hi Justin,
> [...] "*:* AND -myfield:foo*".
>
> If my document contains "myfield:foobar" and "myfield:dog", the document
> would be thrown out because of the first field. I want to keep the
> document because the second field does not match.
I'm assuming that you mistakenly used the same field name above in ("myfield:foobar" and "myfield:dog"), and that you instead meant:
"myfield1:foobar" and "myfield2:dog".
I think you can get what you want by specifying every field in the query - e.g., if each document has the same set of two fields F1 and F2:
(*:* AND -F1:foo*) OR (*:* AND -F2:foo*)
Truth table for four documents:
Doc1: F1:foobar (no-match), F2:dog (match) => match
Doc2: F1:cat (match), F2:dog (match) => match
Doc3: F1:cat (match), F2:foosball (no-match) => match
Doc4: F1:foobar (no-match), F2:foosball (no-match) => no-match
Good luck,
Steve
Re: InverseWildcardQuery
Posted by Justin <cr...@yahoo.com>.
I think you're suggesting, for example, "*:* AND -myfield:foo*".
If my document contains "myfield:foobar" and "myfield:dog", the document would
be thrown out because of the first field. I want to keep the document because
the second field does not match.
Related, is there a way to use wildcards to match the beginning of the field?
org.apache.lucene.queryParser.ParseException: Cannot parse '*:* AND
-myfield:*foo*': '*' or '?' not allowed as first character in WildcardQuery
----- Original Message ----
From: Ian Lea <ia...@gmail.com>
To: java-user@lucene.apache.org
Sent: Fri, July 30, 2010 9:38:26 AM
Subject: Re: InverseWildcardQuery
I can't get my head round exactly what you want, but a standard lucene
technique is a BooleanQuery holding a MatchAllDocsQuery and a second
query, can be anything, having Occur.MUST_NOT. I guess that is a way
of inverting the second query.
--
Ian.
On Fri, Jul 30, 2010 at 3:29 PM, Justin <cr...@yahoo.com> wrote:
> Any hints on making something like an InverseWildcardQuery?
>
> We're trying to find all documents that have at least one field that doesn't
> match the wildcard query.
>
> Or is there a way to inverse any particular query?
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-user-help@lucene.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
Re: InverseWildcardQuery
Posted by Ian Lea <ia...@gmail.com>.
I can't get my head round exactly what you want, but a standard lucene
technique is a BooleanQuery holding a MatchAllDocsQuery and a second
query, can be anything, having Occur.MUST_NOT. I guess that is a way
of inverting the second query.
--
Ian.
On Fri, Jul 30, 2010 at 3:29 PM, Justin <cr...@yahoo.com> wrote:
> Any hints on making something like an InverseWildcardQuery?
>
> We're trying to find all documents that have at least one field that doesn't
> match the wildcard query.
>
> Or is there a way to inverse any particular query?
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-user-help@lucene.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org