DO NOT REPLY [Bug 23964] New: - QueryParser fails when feeding with a stop word with a boosting factor

2003-10-21 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 23964] - QueryParser fails when feeding with a stop word with a boosting factor

2003-10-21 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 23964] - QueryParser fails when feeding with a stop word with a boosting factor

2003-10-21 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 23964] - QueryParser fails when feeding with a stop word with a boosting factor

2003-10-21 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

Re: FileChannel implementation of Directory

2003-10-21 Thread Doug Cutting
Tate Avery wrote: Does anyone know why I might not be seing a performance increase for multiple concurrent threads using my "FileChannelDirectory" ? Are you using a RAID system? If the data is already cached in RAM, then the i/o calls may be so fast that concurrency doesn't make things noticeabl

RE: FileChannel implementation of Directory

2003-10-21 Thread Tate Avery
Thank you Doug. My next tests will be with RAID (RAID0, I believe). My suspicion was that the OS was serializing the disk reads (from IDE or SCSI). But, I wasn't sure how to 'open the gates' for concurrent reads. My index was fairly large (about 3 million docs) and my queries where random (sin

Re: File timestamps

2003-10-21 Thread Doug Cutting
Christoph Goller wrote: What about living the file timestamps as they are and using an additional file per index that contains nothing but a counter (type long) which gets incremented everytime the index is changed (SegmentReader and IndexWriter). I could implement this. I think this is a good ide

Re: File timestamps

2003-10-21 Thread Hani Suleiman
Adding it inside of a file (segments or otherwise) would mean that the file has to be opened to be read...I might be completely wrong here, but wouldn't it be more efficient to have a separate timestamp file, eg something called segments.[timestamp], with appropriate magic to ensure it's atomic

Re: [PATCH] enable subclassing of IndexReader

2003-10-21 Thread Doug Cutting
Doug Cutting wrote: Please find attached a patch which permits subclassing of IndexReader. This is a pretty big change, so I thought I'd let folks try it before I submit it. If anyone tries it, can you please report back on whether it breaks anything? I've already checked that it passes unit t

Re: File timestamps

2003-10-21 Thread Doug Cutting
Maybe I'm misunderstanding your proposal, but the problem is that the resolution of file timestamps is not high enough. On MacOS, HFS files only have 1-second resoution, so one can't use a file's timestamp for versioning unless one is willing to wait a second when checking the version, which s

Re: File timestamps

2003-10-21 Thread Hani Suleiman
Sorry, I should have been clearer, I meant using a file, but putting System.currentTimeMillis() in the filename (or any equivelant versioning number, really), rather than in the file data. Doug Cutting wrote: Maybe I'm misunderstanding your proposal, but the problem is that the resolution of fi

Re: [PATCH] enable subclassing of IndexReader

2003-10-21 Thread Erik Hatcher
+1 I had no objections, so didn't reply to your first message. On Tuesday, October 21, 2003, at 01:17 PM, Doug Cutting wrote: Doug Cutting wrote: Please find attached a patch which permits subclassing of IndexReader. This is a pretty big change, so I thought I'd let folks try it before I submi

cvs commit: jakarta-lucene/src/test/org/apache/lucene/index TestFilterIndexReader.java

2003-10-21 Thread cutting
cutting 2003/10/21 10:59:17 Modified:.CHANGES.txt src/java/org/apache/lucene/index FieldInfos.java IndexReader.java IndexWriter.java MultipleTermPositions.java SegmentMergeInfo.java SegmentMerg

cvs commit: jakarta-lucene/src/java/org/apache/lucene/index FilterIndexReader.java IndexReader.java SegmentReader.java SegmentsReader.java

2003-10-21 Thread cutting
cutting 2003/10/21 11:24:23 Modified:.CHANGES.txt src/java/org/apache/lucene/index FilterIndexReader.java IndexReader.java SegmentReader.java SegmentsReader.java Log: Add IndexReader.undeleteAll(). Revision

1.3 RC2

2003-10-21 Thread Doug Cutting
Should I go ahead and make this release, or should we wait for a fix to the timestamp problem? I'm leaving town Thursday, and can either make this release tomorrow morning, or not until November. My hunch is to go ahead and make an RC release tomorrow, then, in November, when the timestamp pr

Re: 1.3 RC2

2003-10-21 Thread petite_abeille
On Tuesday, Oct 21, 2003, at 20:52 Europe/Amsterdam, Doug Cutting wrote: Should I go ahead and make this release, or should we wait for a fix to the timestamp problem? I'm leaving town Thursday, and can either make this release tomorrow morning, or not until November. My hunch is to go ahead

Re: 1.3 RC2

2003-10-21 Thread Dmitry Serebrennikov
+1 Doug, I didn't have a chance to apply your patches and test them yet. From just a quick review, it looks like everything should be fine. Now that the changes are in CVS, I can more easily check them out. But if the tests pass, I'm not worried. :) Dmitry. Doug Cutting wrote: Should I go ah

Re: 1.3 RC2

2003-10-21 Thread Hani Suleiman
Mmm, while a release would be nice, I think the timestamp thing is a significant enough change that it'd be good to have it in an RC release before final. Doug Cutting wrote: Should I go ahead and make this release, or should we wait for a fix to the timestamp problem? I'm leaving town Thursd

Re: 1.3 RC2

2003-10-21 Thread Erik Hatcher
+1 On Tuesday, October 21, 2003, at 02:52 PM, Doug Cutting wrote: Should I go ahead and make this release, or should we wait for a fix to the timestamp problem? I'm leaving town Thursday, and can either make this release tomorrow morning, or not until November. My hunch is to go ahead and m

Re: 1.3 RC2

2003-10-21 Thread Scott Ganyo
+1 Doug Cutting wrote: Should I go ahead and make this release, or should we wait for a fix to the timestamp problem? I'm leaving town Thursday, and can either make this release tomorrow morning, or not until November. My hunch is to go ahead and make an RC release tomorrow, then, in Novembe

Re: 1.3 RC2

2003-10-21 Thread Otis Gospodnetic
Definitely +1 for the hunch. Otis --- Doug Cutting <[EMAIL PROTECTED]> wrote: > Should I go ahead and make this release, or should we wait for a fix > to > the timestamp problem? I'm leaving town Thursday, and can either > make > this release tomorrow morning, or not until November. My hunch

Re: 1.3 RC2

2003-10-21 Thread Doug Cutting
Hani Suleiman wrote: Mmm, while a release would be nice, I think the timestamp thing is a significant enough change that it'd be good to have it in an RC release before final. Perhaps. So the question today is: should we go ahead and do an RC tomorrow without a timestamp patch? (Unless someone

Re: 1.3 RC2

2003-10-21 Thread Otis Gospodnetic
I guess I should have given my opinion in my +1 email. I think we can live without the timestamp patch for now. This would be a RC release after all, not a real release. Like Doug already said, the timestamp patch can be added after RC2 and before 1.3 final. Otis --- Doug Cutting <[EMAIL PROTEC

Re: File timestamps

2003-10-21 Thread Otis Gospodnetic
Hani is suggesting embedding the time stamp in the file name, so that the file does not need to be opened/read. Instead, one could just look at the file name. It sounds like that would be more efficient indeed, and require one less file to be opened. Otis --- Doug Cutting <[EMAIL PROTECTED]> wr

Re: 1.3 RC2

2003-10-21 Thread Erik Hatcher
I vote to go for it as-is. Release early, release often. If there are issues with any released version, we can always make another release :) Erik On Tuesday, October 21, 2003, at 05:59 PM, Doug Cutting wrote: Hani Suleiman wrote: Mmm, while a release would be nice, I think the timestamp th

Re: 1.3 RC2

2003-10-21 Thread Hani Suleiman
alright alright, I thought that 1.3 final follows RC2, but I suppose there's no legal reason why there can't be an RC 3 ;) On Tuesday, October 21, 2003, at 07:13 PM, Erik Hatcher wrote: I vote to go for it as-is. Release early, release often. If there are issues with any released version, we c

DO NOT REPLY [Bug 23750] - [PATCH] "segments" timestamp patch

2003-10-21 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu