Hello,
These sound very interesting!
I think some of them would go under contrib (as utility tools?) and
others maybe into the core. I've added more detailed comments below.
Stanislav Jordanov wrote:
Hi guys,
For the purpose of our product we've devised a bunch of small tool
classes which
Michael McCandless wrote:
1. IndexRecoverer - assuming the "segments" file is missing or
corrupted, this tool rebuilds it based on the *.cfs (and other) files
found in the index dir (excludes files listed in deletable)
Excellent. I know that various cases of "recovering an index" have
come up
[
http://issues.apache.org/jira/browse/LUCENE-738?page=comments#action_12456216 ]
Doron Cohen commented on LUCENE-738:
I tried two implementations:
(1) writing d-gaps for ids of deleted docs, and
(2) writing d-gaps for indexes of non zero by
[
http://issues.apache.org/jira/browse/LUCENE-738?page=comments#action_12456221 ]
Yonik Seeley commented on LUCENE-738:
-
Doron, I agree with what you have described so far.
One question... are d-gaps written as a 4 byte integer or as a variab
[ http://issues.apache.org/jira/browse/LUCENE-738?page=all ]
Doron Cohen updated LUCENE-738:
---
Attachment: del.dgap.patch.txt
Patch added: "del.dgap.patch.txt" for the above optn "(1) writing d-gaps for
ids of deleted docs".
Patch changes index format, bu
[ http://issues.apache.org/jira/browse/LUCENE-738?page=all ]
Doron Cohen updated LUCENE-738:
---
Lucene Fields: [Patch Available] (was: [New])
> 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_12456224 ]
Doron Cohen commented on LUCENE-738:
> are d-gaps written as a 4 byte integer or as a variable vInt,
> and what drove the decision behind that?
Vints are use
[
http://issues.apache.org/jira/browse/LUCENE-738?page=comments#action_12456239 ]
Yonik Seeley commented on LUCENE-738:
-
Did a quick code review, everything looks good to me.
+1
> read/write .del as d-gaps when the deleted bit vector is suff
[
http://issues.apache.org/jira/browse/LUCENE-732?page=comments#action_12456242 ]
Hoss Man commented on LUCENE-732:
-
+1 for queryparser_datetools2.patch
the only nitpick i have is with the class level javadocs...
* In [EMAIL PROTECTED] RangeQ
[ http://issues.apache.org/jira/browse/LUCENE-732?page=all ]
Hoss Man updated LUCENE-732:
Lucene Fields: [Patch Available] (was: [New, Patch Available])
> Support DateTools in QueryParser
>
>
> Key: LUCENE-73
[ http://issues.apache.org/jira/browse/LUCENE-682?page=all ]
Hoss Man updated LUCENE-682:
Lucene Fields: [Patch Available]
issues has a modest number of notes, and seems to me like it would be very
usefull as more language property files are contributed ...
[
http://issues.apache.org/jira/browse/LUCENE-682?page=comments#action_12456258 ]
Yonik Seeley commented on LUCENE-682:
-
Frankly, I'm not excited about a 6% performance loss so that someone can
customize
a total of 3 tokens that don't add ad
[
http://issues.apache.org/jira/browse/LUCENE-682?page=comments#action_12456294 ]
Yonik Seeley commented on LUCENE-682:
-
Something like this perhaps:
public static String change(String s, String AND, String OR, String NOT) {
int len
[
http://issues.apache.org/jira/browse/LUCENE-682?page=comments#action_12456295 ]
Yonik Seeley commented on LUCENE-682:
-
That's untested code of course... I just noticed that
case '\\' : b.append(s.charAt(++i)); break;
case '\'
14 matches
Mail list logo
