, the approach you would want to take in your application,
but at least it will allow you to use Luke as you have specified.
-- Robert Watkins
On Tue, 1 Nov 2005, Miles Barr wrote:
On Thu, 2005-10-27 at 16:35 -0400, Sharma, Siddharth wrote:
My index has 4 keyword fields and one unindexed field
, the approach you would want to take in your application,
but at least it will allow you to use Luke as you have specified.
-- Robert Watkins
On Tue, 1 Nov 2005, Miles Barr wrote:
On Thu, 2005-10-27 at 16:35 -0400, Sharma, Siddharth wrote:
My index has 4 keyword fields and one unindexed field
obert
Robert Watkins
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Aha! I had, indeed, been fooled by Luke into thinking that the entities
had been converted upon analysis, but you have set me straight.
Thanks,
-- Robert
On Tue, 13 Dec 2005, J.J. Larrea wrote:
Beware of HTML/XML entities in your input stream! The Lucene analyzers (including
StandardAnalyzer
So obvious I missed it (at least that's my excuse). I'm on the road at
the moment and -- can you believe it? -- didn't bring my copy of Lucene
In Action with me! Looks like I'll have to get the source code from
lucenebook.com to crib the analyzer demo code.
Much obliged,
-- Robert
On Tue, 13 Dec
here is, obviously, a fair amount of work involved, but the level of
control is the payoff.
-- Robert
Robert Watkins
[EMAIL PROTECTED]
On Mon, 20 Feb 2006, Erik Hatcher wrote:
Yes, this is what PerFieldAnalyzerWrapper provides for you, as described in
anks!
----
Robert Watkins
[EMAIL PROTECTED]
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
I've been puzzling this one for a while now, and can't figure it out.
The idea is to allow stemmed searches and exact matches (tokenized, but
unstemmed phrase searches) on the same field. The subject of this email
had "same" in quotes, because it's from the search-client perspective
that the sa
Thank you, Chris. You have confirmed what I had all but resigned myself
to (and you summarized my goal precisely). I am sticking with the two
versions of the field and just accepting the fact that the search
clients will need to use my custom query parser.
Even if one doesn't get the answer one w
Thank you, Chris. You have confirmed what I had all but resigned myself
to (and you summarized my goal precisely). I am sticking with the two
versions of the field and just accepting the fact that the search
clients will need to use my custom query parser.
Even if one doesn't get the answer one w
Mark --
Yes please! I'm very interested in the mixing of boolean and proximity
operators. I have also worked on a parser (using JavaCC) but haven't
managed to crack queries such as:
((a OR b) AND c) NEAR (d NOT e)
I can get the parse tree okay, but haven't figured out how to translate
that
Mark --
Don't lose hope! We are migrating from Verity to Lucene, and I know for
a fact that we will have to support the kind of complex queries you talk
about; maybe not /quite/ as complex as your magnificent:
cop | fowl & (fowl | priest & man) ! helicopter ~8 (hillary | tom)
but certainly mo
posted by a Christian Ubbesen. I have tried to contact
him, to see if he had managed to solve this, but have not heard back (hey,
he could well have moved on in 3.5 years!)
Thanks,
-- Robert
Robert Watkins
[EMAIL PROTECTED]
Okay, I only bought your book a few days ago, so I haven't read much
yet! Also, this project is still at the exploratory level, so very
little time has been dedicated to it (the irony is I am currently
spending most of my time trying to work around K2 ... issues). As
such, it will be some time befo
The reason your suggestion is not practical is scalability. In a production
environment you might have, for example, 10,000 stored queries and 10 new
documents a minute. That's a fair bit of load on the system for only one
aspect of a much larger search application.
On Wed, 16 Mar 2005, Dan Funk
Thank you, David, for your very interesting suggestions. As I said
earlier in this thread somewhere, we are still at the exploratory
stage (considering Lucene as a replacement for a commercial engine)
so it will be some time before I can get my hands dirty, but you have
certainly given me some good
efixQuery fits into the
slot left by the [gap] of the PhraseQuery.
Does that sound like I'm on the right track?
-- Robert
Robert Watkins
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMA
the sequence of terms, such as:
( term | term as prefix )+
Am I missing something?
-- Robert
On Tue, 11 Oct 2005, Daniel Naber wrote:
On Dienstag 11 Oktober 2005 15:32, Robert Watkins wrote:
The only idea that comes to mind is to try to combine a PhraseQuery and
a PrefixQuery
Yes
Wonderful! But what about wildcards? I realised after I had sent the
last message that my pattern should have been written:
( term | term as prefix | wildcard term )+
-- Robert
On Tue, 11 Oct 2005, Daniel Naber wrote:
On Dienstag 11 Oktober 2005 22:53, Robert Watkins wrote:
I was under
lable -- to you?
-- Robert
PS -- Would it be possible to avoid going through _all_ the terms in the
TermEnum (that are greater than prefix, of course) by doing something
like:
} while (te.next() && te.term().text().startsWith(prefix));
or would analysis possibly make that unwise?
Thank you, Daniel. Once I get an environment suitable enough I will
certainly give this a whirl.
-- Robert
On Wed, 12 Oct 2005, Daniel Naber wrote:
On Mittwoch 12 Oktober 2005 17:18, Robert Watkins wrote:
Does that sound reasonable -- and scalable -- to you?
I don't think you ne
Robert Watkins
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
22 matches
Mail list logo
