AUTOMATIC REPLY
LUX is closed until 5th January 2009
-
To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-user-h...@lucene.apache.org
AUTOMATIC REPLY
LUX is closed until 5th January 2009
-
To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-user-h...@lucene.apache.org
Hi Erick,
Thanks for the heads up. I understand that I am using an implementation
detail rather than a feature.
Looks like having a single index is the best option. Hence, any
optimizations (to improve indexing speed) you would suggest given that
a) once a doc is added to an index, it will not
You're off in undefined territory. From the docs for the Sort
class:
<<<...Documents must contain a single term in such a field,
and the value of the term should indicate the document's
relative position in a given sort order. The field must be indexed,
but should not be tokenized, ...>
Whatever
For one of our projects - we were planning to have the system of
multiple individual Lucene readers (just read-only instances and no
writes whatsoever ) in different physical machines having their
IndexReader-s warmed up from the same directory for the indices and
working on the same.
I was r
Recently, our lucene index version was upgraded to 2.3.1 and the index had to
be rebuilt for several weeks which made the entire index a total of 20 GB or
so.
After the the rebuild, a weekly sunday task was executed for optimization.
During that time, the optimization failed several times comp
Hi all,
Has anyone been through this issue?
I have documents that have one or more values for the same field. For example:
doc1 = new Document();
doc1.add(new Field("Letter"), "A", ...);
doc1.add(new Field("Letter"), "C", ...);
// doc1.add(other fields);
//write to index
Now I add another docum
Warning! I'm really reaching on this
But it seems you could use TermDocs/TermEnum to
good effect here. Basically, you should be able, for a
given term, use the above to determine whether
doc N had a hit in one of your fields pretty efficiently.
There's even a WildcardTermEnum that will iterat
Hello,
I'm wondering what the best way to accomplish this is.
When a user enters text to search on it customarily searches 3 fields,
resume_text, profile_text, and summary_text, so a standard query would be
something like:
(resume_text:(query) OR profile_text:(query) OR summary_text:(query))
For
OK. Thanks for bringing closure here.
Mike
1world1love wrote:
Michael McCandless-2 wrote:
How did you delete the documents? EG, by docID using IndexReader, by
Term or Query using IndexWriter?
And when you said your previous index had 14488449 docs, was
numDocs()
or maxDoc()?
I
Michael McCandless-2 wrote:
>
>
> How did you delete the documents? EG, by docID using IndexReader, by
> Term or Query using IndexWriter?
>
> And when you said your previous index had 14488449 docs, was numDocs()
> or maxDoc()?
>
>
I deleted by docid. I got the number by numdocs.
Jus
I would second Erick's recommendation - create an arbitrary representation for
NULL such as "NULL" (if you are certain the term "NULL" does not occur in
actual docs. Alternatively, use "NULLNULNULLNULL" or something to that effect.
- Original Message
From: Erick Erickson
To: java-use
Hi Christian,
Typically for public facing applications the desire is to have search results
be sub-second. For some applications waiting even a minute or more is OK.
Otis
--
Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch
- Original Message
> From: Christian Brennsteiner
I think a link is probably enough...
its funny to have "lucene-current.xxx" listed on:
http://archive.apache.org/dist/jakarta/lucene/
On Dec 19, 2008, at 11:25 PM, Chris Hostetter wrote:
a couple of refrences to "Lucene 1.2" in the last few months got me
thinking and made me realize that
Try searching the mailing list archives for a fuller discussion, but
the short answer is usually to index an unique value for your
"null" entries, then search on that, something totally
outrageous like, say AAABBBCCCDDDEEEFFF.
Alternatively, you could create, at startup time, a
Filter of all the d
Well, you haven't run afoul of the usual suspects, that's pretty
clean timing code. I'm afraid I'll have to defer to the people who
know the internals of Lucene.
Best
Erick
On Sun, Dec 21, 2008 at 10:31 PM, Prafulla Kiran
wrote:
> Hi,
>
> Here's the code which I am using to time the query:
>
Hi,
I have problem with lucene search, I am quite new to this. Can some body
help or just push me to who can please.
Problem what I am facing we need search for object whose attribute "chain"
contaning null, but lucene does not help indexing the null values..
how can I achieve this, or please gu
Thanks for your answer.
I already found the reason for the bad performance.
hossman wrote:
>
> don't construct a new LuceneDictionary/IndexReader on every "suggest" call
> ... construct them once, and reuse them for each suggestion.
>
This was the first thing I did, but the effect was not that
18 matches
Mail list logo
