Yonik Seeley wrote:
> Also, I think the extension points are important since
> NewIndexModifier does not (and probably never will be able to) do
> everything people need.
I agree extensions points are nice. Maybe we could leave the
extension points ("doAfterFlushRamSegments", etc.) but merge
NewIndexModifier into IndexWriter?
Though I do worry that by adding these extension points we tie our
hands for later. EG if we at some point improve IndexWriter to be
more like KinoSearch or Ferret, which have drastically different ways
to use RAM to buffer documents, then we will break people who rely on
these extensions points? I guess we could also just make a whole new
writer class at that point. It just feels like it may be too early to
expose the implementation details of how the current writer buffers
things in RAM and builds/flushes a segment on commit.
> There can be very complex ways of identifying documents to be
> deleted.
Agreed. I think we must continue to support deleting from an
IndexReader for these advanced use cases.
> It's also nice knowing when documents in ram will be flushed to
> disk... one reason being that it correlates with document visibility
> if you open a new reader.
Do you mean this is a good use case for the extension point
"doAfterFlushFlushRamSegments"? I agree. Though with LUCENE-710
(adding "commit on close" to IndexWriter) you then have complete
control on visibility to readers.
I also think it's now confusing to users which class (IndexModifier,
NewIndexModifier, IndexWriter) to use to write to an index. I would
prefer a single IndexWriter class now because this is more closely
towards our eventual goal of "use IndexWriter to make changes; use
IndexReader to search/read".
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
