In fact I think we could just continue to use IndexReader to actually
perform the deletions (like the patch(es) in LUCENE-565 and also like
Solr I believe)?
It's just that IndexWriter is the one opening the IndexReader (or
SegmentReaders) in order to flush the deletes, and it's doing so
"within" its session (so that deletes & re-adds are committed into a
single new segments_N).
Ie what we want to avoid is forcing the developer to open/close the
IndexReader in order to do deletes because that "close" is really a
"commit and close".
If this approach works well we could at some point deprecate the
delete* methods on IndexReader and make package protected versions
that IndexWriter calls.
Mike
Grant Ingersoll wrote:
Perhaps the answer would be to add some interfaces, such as (interface
names are just for argument purposes):
IndexWriter -- contains signatures of write methods
DocumentDeleter - contains signatures of deletion methods
IndexReader -signatures of read methods
If this were how users interacted w/ Lucene, then the implementation
could be in the same implementation that unified the working with the
index.
I think we may want to seriously consider, for 3.0, a revision of the
front facing methods such as writing and reading.
On Jan 17, 2007, at 7:46 AM, Nadav Har'El wrote:
On Wed, Jan 17, 2007, Michael McCandless wrote about "Re: adding
"explicit commits" to Lucene?":
Perhaps instead of a single "grand unified Index" class in the future,
we aim to move all index write methods into IndexWriter? This
is then simple for users to use: if you want to change anything about
the index, use an IndexWriter; if you want to do searches, use an
IndexReader. If we aim for this as our eventual goal, LUCENE-565 in
fact gets us quite a bit closer.
It's important to remember, that whatever class knows how to do
deletions,
this class will need to replicate much of the IndexReader functionality.
Why? Because just like an IndexReader, the deleting class needs to
know how
to find documents matching a term, and like an IndexReader (and unlike an
InderWriter) it may need to open all segments, not just the one
segment that
is being written.
So perhaps a "grand unified Index" does make sense, instead of
repeating the
same code and/or functionality in both IndexReader and IndexWriter.
--Nadav Har'El | Wednesday, Jan 17 2007, 27
Tevet 5767
[EMAIL PROTECTED]
|-----------------------------------------
Phone +972-523-790466, ICQ 13349191 |I had a lovely evening.
Unfortunately,
http://nadav.harel.org.il |this wasn't it. - Groucho Marx
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------
Grant Ingersoll
Center for Natural Language Processing
http://www.cnlp.org
Read the Lucene Java FAQ at http://wiki.apache.org/jakarta-lucene/LuceneFAQ
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
