[jira] Commented: (LUCENE-738) read/write .del as d-gaps when the deleted bit vector is sufficiently sparse

[ http://issues.apache.org/jira/browse/LUCENE-738?page=comments#action_12455495 ] Yonik Seeley commented on LUCENE-738: - Sounds like a good idea! > read/write .del as d-gaps when the deleted bit vector is sufficiently sparse > --

Re: Attached proposed modifications to Lucene 2.0 to support Field.Store.Encrypted

(For the record: I have delibierately avoided looking at your patch so far, because i didn't want my opinion on the question of "should Lucene offer encryption services" to be clouded by any specifics of your implimentation. That said...) As it's already been pointed out, an apples to apples com

[jira] Updated: (LUCENE-732) Support DateTools in QueryParser

[ http://issues.apache.org/jira/browse/LUCENE-732?page=all ] Michael Busch updated LUCENE-732: - Summary: Support DateTools in QueryParser (was: Use DateTools instead of deprecated DateField in QueryParser) Changed the summary to better reflect the seco

[jira] Updated: (LUCENE-732) Use DateTools instead of deprecated DateField in QueryParser

[ http://issues.apache.org/jira/browse/LUCENE-732?page=all ] Michael Busch updated LUCENE-732: - Attachment: queryparser_datetools2.patch This new patch contains the changes suggested by Hoss: - by default the QueryParser uses DateField to format dates fo

[jira] Created: (LUCENE-738) read/write .del as d-gaps when the deleted bit vector is sufficiently sparse

read/write .del as d-gaps when the deleted bit vector is sufficiently sparse - Key: LUCENE-738 URL: http://issues.apache.org/jira/browse/LUCENE-738 Project: Lucene - Java

Re: NO_NORMS and fakeNorms

Ah, yes, I forgot about that. I see that byte[] ones now, which is lazily populated and reused. Thanks! Otis - Original Message From: Yonik Seeley <[EMAIL PROTECTED]> To: java-dev@lucene.apache.org Sent: Monday, December 4, 2006 4:20:29 PM Subject: Re: NO_NORMS and fakeNorms On 12/4/

Exposing IndexReader commit()

Hello, I'm wondering about opening up commit() in IndexReader. It's currently "protected". We'd like to be able to control the flushing of deletes to disk, and it looks like that's what IndexReader's commit() does. We tried extending SegmentReader with our own version that overrides commit()

[jira] Updated: (LUCENE-736) Sloppy Phrase Scoring Misbehavior

[ http://issues.apache.org/jira/browse/LUCENE-736?page=all ] Doron Cohen updated LUCENE-736: --- Attachment: sloppy_phrase.patch3.txt Test case - testNonExistingWrappedPhrase - was extended. A bug in the patch (described above) was fixed. All tests pass.

Re: NO_NORMS and fakeNorms

On 12/4/06, Otis Gospodnetic <[EMAIL PROTECTED]> wrote: I was looking at NO_NORMS, but then spotted fakeNorms in SegmentReader. From a quick look it seems that even if NO_NORMS is used on a field, these fakeNorms get generated. (see the patch in http://issues.apache.org/jira/browse/LUCENE-448

Efficiently expunging deletions of recently added documents

Hi All, I'd like to open up the API to mergeSegments() in IndexWriter and am wondering if there are potential problems with this. I use ParallelReader and ParallelWriter (in jira) extensively as these provide the basis for fast bulk updates of small metadata fields. ParallelReader requires that

[jira] Commented: (LUCENE-736) Sloppy Phrase Scoring Misbehavior

[ http://issues.apache.org/jira/browse/LUCENE-736?page=comments#action_12455422 ] Doron Cohen commented on LUCENE-736: There is a bug in my recent patch (sloppy_phrase.patch2.txt): - for the case of phrase with repetitions, some additional co

NO_NORMS and fakeNorms

Hi, I was looking at NO_NORMS, but then spotted fakeNorms in SegmentReader. From a quick look it seems that even if NO_NORMS is used on a field, these fakeNorms get generated. (see the patch in http://issues.apache.org/jira/browse/LUCENE-448 ). Why is that? Why are fake norms needed, and if

[jira] Resolved: (LUCENE-731) Simple attempt at adding and searching at the same time fails.

[ http://issues.apache.org/jira/browse/LUCENE-731?page=all ] Michael McCandless resolved LUCENE-731. --- Fix Version/s: 2.1 Resolution: Invalid OK, this is how Lucene is designed. I agree this was not clearly called out in the FAQs so I've add

Re: Regarding adding one more factor in lucene scoring formula

http://lucene.apache.org/java/docs/scoring.html may be of some help, plus the Javadocs and the code of course. What is it you are trying to do? Perhaps others have done similar things. -Grant On Dec 4, 2006, at 7:24 AM, Sajid Khan wrote: Hi all, I need to add one more factor(lik

Regarding adding one more factor in lucene scoring formula

Hi all, I need to add one more factor(like tf, idf .) in the lucene scoring formula. But i am not getting any idea of where should i update the code in Lucene. Can anybody please help me to solve the problem? Ragards Sajid Khan -- View this message in context: http://www.nabbl

[jira] Closed: (LUCENE-412) Escaping special characters in Query doesn't return correct results.

[ http://issues.apache.org/jira/browse/LUCENE-412?page=all ] Michael Busch closed LUCENE-412. Resolution: Cannot Reproduce Assignee: (was: Lucene Developers) As stated earlier, this is not reproduceable (anymore). > Escaping special characters

[jira] Closed: (LUCENE-624) Segment size limit for compound files

[ http://issues.apache.org/jira/browse/LUCENE-624?page=all ] Michael Busch closed LUCENE-624. Resolution: Won't Fix Assignee: Michael Busch I'm closing this issue, because: - no votes or comments for almost half a year - only indexing performance b