[ 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
[ 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
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
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
[ 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
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
[
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
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
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
[ 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.
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()
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/
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
[ 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
[ 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
(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
[
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
> --
17 matches
Mail list logo