Somebody recently submitted a NoOpDirectory, which may help you detect
a corrupt index. There are no tools that will fix a corrupt index,
though.
Otis
--- Chris Lu <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Is there any way to detect the index's integrity?
> Sometimes I came upon exceptions like thes
Hi,
Is there any way to detect the index's integrity?
Sometimes I came upon exceptions like these. If it happens, my only way
is to delete the corrupted index.
* Exception in thread "main" java.io.IOException : read past EOF
* java.lang.ArrayIndexOutOfBoundsException
Being able to verify t
Erik Hatcher ehatchersolutions.com> writes:
> Lucene's index works with any String. But, when dealing with numbers
> and dates such that range queries work, they need to be formatted in a
> way that makes them orderable.
What I am suggesting here is storing numeric values as unsigned binary v
Using a zero-padded number like 0001 is fine for both range queries
and for integer-based sorting. Are you finding otherwise?
Erik
On Mar 18, 2005, at 12:46 PM, Yonik Seeley wrote:
There is prefix compression used on term values. So you could pad
numbers with lots of leading zeros a
Technorati uses Lucene.
Otis
--- Aad Nales <[EMAIL PROTECTED]> wrote:
> We have been using Lucene for quite some time now but recently a
> customer asked to what level Lucene has scaled and if any public
> references to such projects exist. The (potential) customer is
> looking
> towards an i
Hi guys,
Just trying to understand where problems can occur.
Maybe I need to describe our indexing process some more.
We create new indexes as "index parts" with Documents that are supposed to
contain unique ID key fields.
These "index parts" get merged into two separate indexes: a main index
> There is prefix compression used on term values. So you could pad
> numbers with lots of leading zeros and not incur much additional
> size... 0001, for example.
Interesting...
One annoyance I have run across is the impedance mismatch between
range queries and sorting.
If your terms a
On Mar 18, 2005, at 11:21 AM, John Patterson wrote:
Because Lucene deals with String's lexicographically ordered.
I thought lexographical ordering simply used the Unicode value of the
chars and
so would also work with non alpa-numeric strings.
Lucene's index works with any String. But, when deal
> Because Lucene deals with String's lexicographically ordered.
I thought lexographical ordering simply used the Unicode value of the chars and
so would also work with non alpa-numeric strings.
> Is there an issue you're encountering?
No issue - I will soon need to add a lot of unstored numeric
We have been using Lucene for quite some time now but recently a
customer asked to what level Lucene has scaled and if any public
references to such projects exist. The (potential) customer is looking
towards an index based on 15M (million) documents. Do any of you know of
public sites that usi
Because Lucene deals with String's lexicographically ordered.
Is there an issue you're encountering?
Erik
On Mar 18, 2005, at 4:31 AM, John Patterson wrote:
Hi all,
I was wondering why NumberTools and DateTools create strings
restricted to
alpha-numberic values?
John.
> > However, after optimizing, suddenly those new documents
> > appear. Its almost as if the new segments are not being read
> > by the IndexReader.
>
> You need to close IndexWriter before open IndexReader. Or reopen
> IndexReader.
>
> See TestIndexReader.java:: private void deleteReaderWriterC
Hi all,
I was wondering why NumberTools and DateTools create strings restricted to
alpha-numberic values?
John.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
13 matches
Mail list logo
