[jira] Resolved: (LUCENE-509) Performance optimization when retrieving a single field from a document

2006-08-12 Thread Otis Gospodnetic (JIRA)
[ http://issues.apache.org/jira/browse/LUCENE-509?page=all ] Otis Gospodnetic resolved LUCENE-509. - Resolution: Won't Fix It looks like this was superseded by LUCENE-545, whose patches have been applied to the trunk. > Performance optimization when

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

2006-08-12 Thread Otis Gospodnetic (JIRA)
[ http://issues.apache.org/jira/browse/LUCENE-648?page=comments#action_12427735 ] Otis Gospodnetic commented on LUCENE-648: - I agree. I like the idea of externalizing this, too, as suggested by Robert on the mailing list. > Allow chang

[jira] Resolved: (LUCENE-629) Performance improvement for merging stored, compressed fields

2006-08-12 Thread Otis Gospodnetic (JIRA)
[ http://issues.apache.org/jira/browse/LUCENE-629?page=all ] Otis Gospodnetic resolved LUCENE-629. - Resolution: Fixed Committed. Muchos gracias! > Performance improvement for merging stored, compressed fields > --

[jira] Commented: (LUCENE-629) Performance improvement for merging stored, compressed fields

2006-08-12 Thread Otis Gospodnetic (JIRA)
[ http://issues.apache.org/jira/browse/LUCENE-629?page=comments#action_12427733 ] Otis Gospodnetic commented on LUCENE-629: - This looks fine to me, patch applied after a bit of persuading, and unit tests all pass. I'll commit this in a

GData - Server documentation online @ wiki.apache.org

2006-08-12 Thread Simon Willnauer
Hello java-devs, I added the documentation for the gdata server to the lucene wiki @ http://wiki.apache.org/jakarta-lucene/GdataServer -- Daniel Naber will hate me for that receiving 4 million email in 3 days about changes in the wiki ;) hey if you feel bored just give it a go :). No honestly If

Re: Strange behavior of positionIncrementGap

2006-08-12 Thread Chuck Williams
Yonik Seeley wrote on 08/12/2006 05:08 AM: > On 8/11/06, Chuck Williams <[EMAIL PROTECTED]> wrote: >> 1) a b C D ...results in: _gap_ _gap_ C _gap_ D >> 2) a B C D ...results in: _gap_ B _gap_ C _gap_ D >> 3) A b c D ...results in: A _gap_ _gap_ _gap_ D >> >> This seems a natural behavior and

Re: Strange behavior of positionIncrementGap

2006-08-12 Thread Yonik Seeley
On 8/11/06, Chuck Williams <[EMAIL PROTECTED]> wrote: 1) a b C D ...results in: _gap_ _gap_ C _gap_ D 2) a B C D ...results in: _gap_ B _gap_ C _gap_ D 3) A b c D ...results in: A _gap_ _gap_ _gap_ D This seems a natural behavior and is consistent with the use cases you describe (which are es

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

2006-08-12 Thread Nicolas Lalevée
Le Vendredi 11 Août 2006 16:00, robert engels a écrit : > If you make the compression external this is already done. In order > to do what the poster requires, you still need to read and update > fields without reading the entire document. You just do this at a > binary field level, and do all of h