On Jan 23, 2008 6:34 AM, Michael McCandless <[EMAIL PROTECTED]> wrote:
> writer.freezeDocIDs();
> try {
> get docIDs from somewhere & call writer.deleteByDocID
> } finally {
> writer.unfreezeDocIDs();
> }
Interesting idea, but would require the IndexWriter to flush the
buffered docs so an IndexReader could be created fro them. (or would
require the existence of an UnflushedDocumentsIndexReader)
> If we went that route, we'd need to expose methods in IndexWriter to
> let you get reader(s), and, to then delete by docID.
Right... I had envisioned a callback that was called after a new
segment was created/flushed that passed IndexReader[]. In an
environment of mixed deletes and adds, it would avoid slowing down the
indexing part by limiting where the deletes happen.
It does put a little more burden on the user, but a slightly harder
(but more powerful / more efficient) API is preferable since easier
APIs can always be built on top (but not vice-versa).
> I do like the idea of a UID field, but I'm a bit nervous about having
> the "core" maintain it
+1
-Yonik
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
