Agreed. The interface I proposed supports both sequential and random
access to the filter - hiding the implementation.
On Jul 7, 2006, at 10:10 PM, Yonik Seeley wrote:
On 7/7/06, robert engels <[EMAIL PROTECTED]> wrote:
Exactly. I have been watching to see how the new filer interface
works
DM Smith wrote on 07/07/2006 07:07 PM:
> Otis,
> First let me say, I don't want to rehash the arguments for or
> against Java 1.5.
This is an emotional issue for people on both sides.
> However, I think you have identified that the core people need to
> make a decision and the rest of us
On 7/7/06, robert engels <[EMAIL PROTECTED]> wrote:
Exactly. I have been watching to see how the new filer interface
works out for 2.0. I am still not certain why it is so involved.
I still think
interface Filter {
boolean include(int doc);
int nextInclude(int doc);
}
should suffice.
Exactly. I have been watching to see how the new filer interface
works out for 2.0. I am still not certain why it is so involved.
I still think
interface Filter {
boolean include(int doc);
int nextInclude(int doc);
}
should suffice.
On Jul 7, 2006, at 9:53 PM, Yonik Seeley wrote:
Thi
This might be even better in conjunction with moving away from BitSet
to some sort of interface like DocNrSkipper... that way you would
never have to combine the filters into a single BitSet.
-Yonik
http://incubator.apache.org/solr Solr, the open-source Lucene search server
On 7/7/06, robert en
Otis,
First let me say, I don't want to rehash the arguments for or
against Java 1.5. We can all go back and read the last two major
threads on the issue. I don't think there is anything new to say.
However, I think statements like:
"no strong arguments" (I think the
I don't think there is any leak at all. the problem was the caller
was maintaining a reference to the reader after close was called
(which prevents usage anyway), and wanted to free some of the
underlying memory - kind of pointless, he should just release the ref
to the IndexReader (since i
I implemented it and it works great. I didn't worry about the
deletions since by the time a filter is used the deleted documents
are already removed by the query. The only problem that arose out of
this was for things like the ConstantScoreQuery (which uses a filter)
- I needed to modify th
[
http://issues.apache.org/jira/browse/LUCENE-623?page=comments#action_12419805 ]
Yonik Seeley commented on LUCENE-623:
-
Just out of curiousity, does Lucene hold onto a RAMDirectory instance somewhere
after it has called close on it? If so, that would
I'm no segments/MultiReader expert, but your idea sounds good to me ... it
seems like it would certainly work in the "new segments" situation.
One thing i don't see you mention is dealing with deletions ... i'm not
sure if deleting documents cause the version number of an IndexReader to
change or
When one interleaves adds and deletes, it isn't the case that
indexreaders and indexwriters need to be opened and closed each
interleave.
To clarify, higher level (application level) adds and deletes can be
managed at a lower level such that index readers and writers aren't
continually opened an
Hi Chuck,
I think bulk update would be good (although I'm not sure how it would be
different from batching deletes and adds, but I'm sure there is a difference,
or else you wouldn't have done it).
Java 1.5 - no conclusion, but personally I felt:
- no strong arguments for 1.4, only a few people a
On Thu, Jul 06, 2006, Yonik Seeley wrote about "Re: [jira] Commented:
(LUCENE-565) Supporting deleteDocuments in IndexWriter (Code and Performance
Results Provided)":
>..
> When one interleaves adds and deletes, it isn't the case that
> indexreaders and indexwriters need to be opened and closed e
13 matches
Mail list logo
