mentWriter could access it??? Is it a clean way to do?
- Original Message -
From: "Doug Cutting" <[EMAIL PROTECTED]>
To: "Lucene Users List" <[EMAIL PROTECTED]>
Sent: Thursday, July 15, 2004 11:06 PM
Subject: Re: release & migration plan
fp235-
ramDirectory to package
so that the DocumentWriter could access it??? Is it a clean way to do?
- Original Message -
From: "Doug Cutting" <[EMAIL PROTECTED]>
To: "Lucene Users List" <[EMAIL PROTECTED]>
Sent: Thursday, July 15, 2004 11:06 PM
Subject: Re: rele
I have placed Doug's original list on the wiki at
http://wiki.apache.org/jakarta-lucene/Lucene2Whiteboard
Perhaps the wiki makes the best "whiteboard" for Lucene 2.0
brainstorming.
Erik
On Jul 12, 2004, at 1:09 PM, Doug Cutting wrote:
I think perhaps it is time to make some incompatib
A couple of weeks ago Bernhard proposed a patch concerning
the version number of an index. He proposed to initialize
it with the current time in ms. This simple change solves
a problem when an index gets deleted a new index is generated
in the same directory, and an old IndexReader is still existin
Maxim Patramanskij wrote:
Since the changes, proposed and made by Aviran to FieldInfos class
made Lucene java 1 incompatible, but can give us some reasonable
performance gain, shouldn't we go ahead with the whole Hashtable ->
HashMap and Vector -> ArrayList replacement arround the code to have
even
I agree. It would be nice to finally migrate to java2 code and work
on the optimizations made available in the later jvm's.
On Tue, 13 Jul 2004 15:14:56 +0300, Maxim Patramanskij <[EMAIL PROTECTED]> wrote:
> Hello Doug.
>
> There are a lot of Lucene classes still use Vector & Hashtable instead
>
PROTECTED]>
Sent: Monday, July 12, 2004 7:34 PM
Subject: Re: release & migration plan
> fp235-5 wrote:
> > I'd like to be able to modify the indexInterval (tii file) from the
IndexWriter.
> > I tried it recently and it proved to increase performances, especially
for large
Hello Doug.
There are a lot of Lucene classes still use Vector & Hashtable instead
of ArrayList and HashMap because of compatibility reason with java 1.
Since the changes, proposed and made by Aviran to FieldInfos class
made Lucene java 1 incompatible, but can give us some reasonable
performance
I don't remember what was decided for exception handling. What I do
remember is a discussion about the BooleanQuery$TooManyClauses where
option 3 was popular for the "next big release" ;)
http://www.mail-archive.com/[EMAIL PROTECTED]/msg04050.html
sv
On Mon, 12 Jul 2004, Jon Schuster wrote:
>
the Lucene search capabilities, tokenizers, remote searches, etc.
Robert
-Original Message-
From: Doug Cutting [mailto:[EMAIL PROTECTED]
Sent: Monday, July 12, 2004 12:45 PM
To: Lucene Developers List
Subject: Re: release & migration plan
Robert Engels wrote:
> I think the Inde
Robert Engels wrote:
I think the IndexReader and IndexWriter should be interfaces, and change the
codebase to use the interface where possible.
I agree that IndexReader should be an interface.
I'm less convinced about IndexWriter. I have a little harder time
imagining alternate, pluggable impleme
fp235-5 wrote:
I'd like to be able to modify the indexInterval (tii file) from the IndexWriter.
I tried it recently and it proved to increase performances, especially for large
queries. Do you think there would be a reason not to give access to that parameter?
I agree. We should add this, but w
Doug Cutting wrote:
> 3. Replace public IndexWriter fields (mergeFactor, minMergeDocs, etc.)
> with get/set accessors. Also, minMergeDocs should be renamed
> maxBufferedDocs.
I'd also suggest changing the static field maxClauseCount in BooleanQuery to
use a getter/setter and eliminate the Syst
& migration plan
I think perhaps it is time to make some incompatible changes to Lucene's
API. There are a number of places where it is showing its age. I'd
like to try to make as many API changes at once as is possible, so that
folks only have to port application code once.
I propose
I think perhaps it is time to make some incompatible changes to Lucene's
API. There are a number of places where it is showing its age. I'd
like to try to make as many API changes at once as is possible, so that
folks only have to port application code once.
I propose we do this as follows:
1
15 matches
Mail list logo
