[jira] Commented: (LUCENE-584) Decouple Filter from BitSet

2006-09-15 Thread Paul Elschot (JIRA)
[ http://issues.apache.org/jira/browse/LUCENE-584?page=comments#action_12434901 ] Paul Elschot commented on LUCENE-584: - In the inheritance from Matcher to Scorer there is an asymmetry in this patch. Matcher provides a default implementation

[jira] Commented: (LUCENE-671) Hashtable based Document

2006-09-15 Thread Chris (JIRA)
[ http://issues.apache.org/jira/browse/LUCENE-671?page=comments#action_12434958 ] Chris commented on LUCENE-671: -- > It is to keep folks from thinking, if they subclass Document, that instances > of their subclass will be returned to them in search

Delay Problem Adding a document to existing index

2006-09-15 Thread sunildm4u
Hi I am new to lucene..In my project we are implementing serch engine through lucene.we have lacs of records.The problem is Once if i index 5 records its takes approximation 20 min. Now thnk i want to add 5 more records to database. if i use IndexWriter indexWriter = new IndexWrit

Re: [jira] Commented: (LUCENE-665) temporary file access denied on Windows

2006-09-15 Thread Yonik Seeley
On 9/15/06, robert engels <[EMAIL PROTECTED]> wrote: Why not just use a dedicated server with an HTTP/TCP listener and let it respond to Lucene queries. If you have more than one server to handle the load, you need to distribute the index to all the search boxes. NFS is an easy way, but I imag

Re: [jira] Commented: (LUCENE-665) temporary file access denied on Windows

2006-09-15 Thread robert engels
Correct, but if you are using a distributing index, you should make copies of it, not access the same index (on one machine) from multiple machines. If doing this, you would still need some sort of server process on the master, and if that is available, it can control the distribution of th

Re: [jira] Commented: (LUCENE-665) temporary file access denied on Windows

2006-09-15 Thread Michael McCandless
Yonik Seeley wrote: > If it will happen so rarely, make it simpler and go directly for > segments_(N-1)... (treat it like your previous plan if segments_N.done > hadn't been written yet). Yes, true, we could just fall back to the prior segments_(N-1) file in this case. Though that means the rea

[jira] Resolved: (LUCENE-648) Allow changing of ZIP compression level for compressed fields

2006-09-15 Thread Grant Ingersoll (JIRA)
[ http://issues.apache.org/jira/browse/LUCENE-648?page=all ] Grant Ingersoll resolved LUCENE-648. Resolution: Won't Fix Won't fix, as I think it is agreed that compression should be handled outside of Lucene and then stored as a binary value > Allo

[jira] Updated: (LUCENE-565) Supporting deleteDocuments in IndexWriter (Code and Performance Results Provided)

2006-09-15 Thread Anonymous (JIRA)
[ http://issues.apache.org/jira/browse/LUCENE-565?page=all ] Attachment: KeepDocCount0Segment.Sept15.patch > Supporting deleteDocuments in IndexWriter (Code and Performance Results > Provided) > - > >

[jira] Commented: (LUCENE-672) new merge policy

2006-09-15 Thread Ning Li (JIRA)
[ http://issues.apache.org/jira/browse/LUCENE-672?page=comments#action_12435174 ] Ning Li commented on LUCENE-672: A small fix named KeepDocCount0Segment.Sept15.patch is attached to LUCENE-565 (can't attach here). In mergeSegments(...), if the