age
From: Steven A Rowe
To: "java-user@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
> > 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
]" 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
To: "java-user@lucene.apache.org
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 valu
time may be crazy, I don't know.
- Original Message
From: Steven A Rowe
To: "java-user@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
>
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'
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 wan
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 n
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
To: java-user@lucene.apache.org
Sent: Fri, July 30, 2010 10:41:13 AM
Subject: RE: Inve
hetaphi.de
eMail: u...@thetaphi.de
> -Original Message-
> From: Ian Lea [mailto:ian@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, "*:* A
> 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.
: 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 gues
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 wrote
13 matches
Mail list logo
