There were all of the links I could find:
http://findmeajob.wordpress.com/2007/07/31/lucene-singlesearcher-vs-multisearcher/
http://archives.devshed.com/forums/java-118/how-do-lucene-ids-work-with-multireader-and-multisearcher-993682.html
It has been only out of personal experimentation.
This is going to get really sticky given StandardAnalyzer. Let's say that
you have
codesearch:B05 1
codesearch:B05 2
codesearch:B05 3
When you index these, you'll index tokens B05, 1, 2, 3, along with
positional information. How to say between 1 and 3 becomes a problem,
although it *might* work
Thanks for the tip. I tried your experiment and, sure enough, it works just
fine, so it's not the contents but obviously some other behavior of my custom
reader. (Does the analyzer require that mark and reset be implemented, for
example? I did not implement them.)
The stack trace is as
Hello, I've been exploring usage of the spellcheck feature via solr 1.3. I
have it working, but there are some issues I'm seeing that make it less
useful than it could be. Response on the solr-user mailing list has been
limited. I'm guessing the reason may be that I'm asking about issues which
If you capture the exact text produced by the reader, and wrap it in a
StringReader and pass that to StandardAnalyzer, do you then see the
same exception?
Can you post the full stack trace on 2.3.2?
Mike
Edwin Smith wrote:
I upgraded to the latest, 3.3.2 and had the same problem, even
Hello Anusham,
My intention is to shard the index after every 7 days (week). After 30 days,
(4th week) the first DB may get deleted. At any point of time i will be
maitaining 3 to 4 DB.
I want to know the pros and cons of the MultiSearcher or Index sharding
approach. Any web links would be
I found it. My reader was returning 0 at the end of the stream instead of -1.
Doh.
Thanks again for the suggestions. They did ultimately lead me to the right
answer.
Ed
- Original Message
From: Edwin Smith [EMAIL PROTECTED]
To: java-user@lucene.apache.org
Sent: Tuesday, October
Guys,
I'm adding multiple fields with the same name to a document as Store.YES,
Indexed.TOKENIZED and it seems that only the last field entered is indexed.
I read about this somewhere her but now I can't find it, naturally. Is there
a work around? does someone have a pointer to this discussion?
Thanks Erick,
Yes PerFieldAnalyzerWrapper is my friend :).
Another related question, I'm putting these values into a document in fields
with the same name. 'codesearch' e.g.
codesearch, B05 1
codesearch, Q070301 4 etc.
I read where only the last field entered is actually indexed but I can't
Let's see the indexing code. It is perfectly reasonable to
add data to a field multiple times, so I suspect you're
doing something wrong.
What evidence do you have that it's only the last field that's
indexed?
Best
Erick
On Tue, Oct 7, 2008 at 1:28 PM, John Griffin [EMAIL PROTECTED]wrote:
See below (and your other mail)
On Tue, Oct 7, 2008 at 1:59 PM, John G [EMAIL PROTECTED] wrote:
Thanks Erick,
Yes PerFieldAnalyzerWrapper is my friend :).
Another related question, I'm putting these values into a document in
fields
with the same name. 'codesearch' e.g.
codesearch, B05
Not sure if I fully get it, but bear with me...
Inline below.
On Oct 6, 2008, at 11:37 PM, Alexander Devine wrote:
Hi Luceners,
I have a particular sorting problem and I wanted some advice on what
the
best implementation approach would be. We currently use Lucene as the
searching engine
Thanks very much for your response, and for pointing me in the direction
towards Function Queries - you saved me a ton of time! You're right, that
seems to be a much better fit for what I am doing. My responses are below.
On Tue, Oct 7, 2008 at 9:11 PM, Grant Ingersoll [EMAIL PROTECTED] wrote:
13 matches
Mail list logo
