On Fri, Feb 09, 2007, jian chen wrote about "Re: NewIndexModifier - - -
DeletingIndexWriter":
> Following the Lucene dev mailing list for sometime now, I am concerned that
> lucene is slowing losing all the simplicity and become a complicated mess.
> I think keeping IndexReader and IndexWriter the
Hi,
Recent changes I made to contrib/benchmark, are using
the HTML parser from contrib/demo.
I just noticed that the dependencies in benchmark/build.xml do
not cover this, nor the class path - apparently I tested this
with an IDE only. Sorry for this.
To fix this I can add a dependency in the d
: You are correct on that point, but it seems rather difficult for you
: to do the range caching and have it work across any document updates
: (unless a lot more notification interfaces are added to Lucene), so I
: guess I don't see the point of your caching.
i haven't read the patch, but based
[
https://issues.apache.org/jira/browse/LUCENE-799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grant Ingersoll reassigned LUCENE-799:
--
Assignee: Grant Ingersoll
> Garbage data when reading a compressed, text field, lazily
[
https://issues.apache.org/jira/browse/LUCENE-565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12472499
]
Yonik Seeley commented on LUCENE-565:
-
OK I moved NewIndexModifier's methods into IndexWriter and did some
small
[
https://issues.apache.org/jira/browse/LUCENE-799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Klaas updated LUCENE-799:
--
Attachment: CompressedLazyTextPatch.patch
test case and fix
> Garbage data when reading a compressed,
Garbage data when reading a compressed, text field, lazily
--
Key: LUCENE-799
URL: https://issues.apache.org/jira/browse/LUCENE-799
Project: Lucene - Java
Issue Type: Bug
Comp
You are correct on that point, but it seems rather difficult for you
to do the range caching and have it work across any document updates
(unless a lot more notification interfaces are added to Lucene), so I
guess I don't see the point of your caching.
Given, a sample date range:
01/01/200
Thanks for the pointer, Robert.
Was that the "MultiSegmentQueryFilter enhancement for interactive
indexes?" thread?
If so, was that not a solution to caching sets in the event of variable
index content rather than my approach which is for caching sets in the
event of variable query ranges? M
FYI, I posted a fully working version of this several months ago - it
uses the natural segment boundaries to break a filter into multiple
filters for caching.
On Feb 12, 2007, at 5:39 PM, Mark Harwood (JIRA) wrote:
Factory for RangeFilters that caches sections of ranges to reduce
disk read
[
https://issues.apache.org/jira/browse/LUCENE-798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Harwood updated LUCENE-798:
Attachment: CachedRangesFilterFactory.java
> Factory for RangeFilters that caches sections of range
Factory for RangeFilters that caches sections of ranges to reduce disk reads
Key: LUCENE-798
URL: https://issues.apache.org/jira/browse/LUCENE-798
Project: Lucene - Java
12 matches
Mail list logo
