Doug Cutting wrote:
Michael McCandless wrote:
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.
I think this is a valid concern. Can the extension points be kept
package-private? It makes them awkward to use, since non-core code must
add things in org.apache.lucene.index. But we shouldn't make something
public that we don't intend to support long-term. Deprecation is for
unforseen changes.
Good idea: I agree the extensions hooks can and should have "package"
protection. I will make that change.
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".
+1, with qualifications. A single IndexWriter would be ideal, so long
as it doesn't have public methods that cannot be supported long-term
(see above), and it doesn't impact non-deleting uses (which Hoss assures
us it won't).
Good idea: I agree the extensions hooks can and should have "package"
protection. I will make that change.
I agree w/ Hoss: the way NewIndexModifier works, if you don't do any
deletes then there's no added cost (well, only some if statements) to
the "addDocument only" case because no readers are opened during the
flush when there are no deletes. Maybe the original patch was
different in this regard?
OK I will work out a patch to merge back the methods into IndexWriter,
remove NewIndexModifier, and package protect the extensions hooks.
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
