OK, interesting, thanks. What do you use the deletedDocs iterator for?
Yes, MatchAllDocsQuery should soon be fixed to not use the
synchronized IndexReader.isDeleted method internally:
https://issues.apache.org/jira/browse/LUCENE-1316
Mike
John Wang wrote:
Mike:
"We are considering replacing the current random-access
IndexReader.isDeleted(int docID) method with an iterator & skipTo
(DocIdSet) access that would let you iterate through the deleted
docIDs, instead."
This is exactly what we are doing. We do have to however, build
the
internal DocIdSet from isDeleted call. It would be great if this is
provided
thru the api.
I am also assuming MatchAllDocsQuery is fixed to avoid
isDeleted call?
-John
On Fri, Jan 23, 2009 at 12:25 PM, Michael McCandless <
luc...@mikemccandless.com> wrote:
We are considering replacing the current random-access
IndexReader.isDeleted(int docID) method with an iterator & skipTo
(DocIdSet) access that would let you iterate through the deleted
docIDs, instead.
At the same time we would move to a new API to replace
IndexReader.document(int docID) that would no longer check whether
the
document is deleted.
This is being discussed now under several Jira issues and on
java-dev.
Would this be a problem for any Lucene applications out there?
How is isDeleted used today (outside of Lucene)? Normally an
IndexSearcher would never return a deleted document, and so "in
theory" a deleted docID should never "escape" Lucene's APIs.
So I'm curious what applications in fact rely on isDeleted, and how
that method is being used...
Thanks,
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-user-h...@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-user-h...@lucene.apache.org
