Hello,
I believe those two versions don't have compatible indices:
http://www.lucenebook.com/search?query=clucene+compatible
But CLucene team has been pretty active, so I'm not sure where they are
currently in terms of index compatibility.
Otis
--- Chandrashekhar <[EMAIL PROTECTED]> wrote:
>
Hi All,
I am using java lucene 1.3 to index content repository and want to use
clucene 0.8.10 for merge and search on these index files. search works well
but while merging two index files i am getting "term out of order"
exception.
So just wanted to know is there any difference between file format
Hi,
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> However, after optimizing, suddenly those new documents
> appear. Its almost as if the new segments are not being read
> by the IndexReader.
>
> Any thoughts?
You need to close IndexWriter before open IndexReader. Or reopen
IndexRe
Hi guys,
We were noticing some odd behavior recently with our indexes.
We have a process that adds new documents into our indexes. When we iterate
through all the documents through an IndexReader, we're not seeing the new
documents and we're not seeing the new documents when we run a search.
That's a great technique - thanks for sharing it!
Erik
On Mar 14, 2005, at 6:54 AM, Volodymyr Bychkoviak wrote:
Hi all.
I have large index of documents (about 1.6 millions)
One field (for example called “number”) contains string of digits.
I need to do wildcard search on this field such as
Robert Watkins wrote:
Thank you, David, for your very interesting suggestions.
You're welcome, it's a fun problem.
Unless there's a requirement to the contrary, I would try to only
execute the queries, say, 1x/day, and try to avoid all the cool
optimizations by default - this uses one of those fi
My epoch looks like 1110816121 but is represented by a string.
-Original Message-
From: Erik Hatcher [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 17, 2005 11:41 AM
To: java-user@lucene.apache.org
Subject: Re: search performace
On Mar 17, 2005, at 11:13 AM, Michael Celona wrote:
> Epo
On Mar 17, 2005, at 11:13 AM, Michael Celona wrote:
Epoch is in seconds...
But you still haven't provided the *type* of epoch. It's a Date? a
String? What do the string values look like?
I am also forced to used a date filter on most of
searches... how bad is the performance hit of that.
Only
Epoch is in seconds... I am also forced to used a date filter on most of
searches... how bad is the performance hit of that.
-Original Message-
From: Erik Hatcher [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 17, 2005 9:54 AM
To: java-user@lucene.apache.org
Subject: Re: search performa
Is epoch a Date? or a String? If a String, what format is it?
Sorting by a Date keyword field will be sorting as a String value,
which is a fair bit more resource intensive than if it was numeric.
Try using a purely numeric field (though as a String) that can be
represented as an int be sure t
I think this scheme is not misleading any users. We are not putting
"meaningless" keywords into the pages to get the page rank. That would
be against google's policy. correct?
On Thu, 17 Mar 2005 07:55:31 -0500, Kevin L. Cobb
<[EMAIL PROTECTED]> wrote:
> I worked on a website that had the same is
I am sorting against an epoch time stored in my index. By using:
contactDocument.add( Field.Keyword( "epoch_time", epoch );
Then I sort by this field. My search time is in the order of 3sec on an
index of about 6G using simple searches against a text field. By using
boosts I was hoping to incre
Hi,
I need a field to store an int value. It need not be indexed or
tokenized. The obvious way to store it is of course to convert to a
String. I wonder however, if something like this would work too:
StringBuffer sb = new StringBuffer();
sb.append((char)(i&0x))
.append((char)(i>>16))
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
I worked on a website that had the same issue. We made a "search engine"
page that listed all the documents that we wanted to index as links to
documents that contained summaries of those documents with links to the
entire document on the limited access site - Google won't be able to
follow these l
On Thursday 17 March 2005 09:20, David Spencer wrote:
> Robert Watkins wrote:
>
> > 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 sy
Hi,
I am not even sure what can of worms I open with this suggestion but:
Suppose that one of my 10.000 queries results in a set of documents
(A,B,.., N)
Suppose I generate a new document from this 'search result history' and
store this in a new index
Suppose I take the new document and (not sure
Robert Watkins wrote:
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.
Fun, inter
18 matches
Mail list logo
