Grant Ingersoll wrote:
On Jan 16, 2007, at 3:55 PM, Michael McCandless wrote:
Doron Cohen wrote:
Michael McCandless <[EMAIL PROTECTED]> wrote on 16/01/2007
12:13:47:
Ning Li wrote:
Re those 2 ideas: I do agree the whole division of certain kinds of
index changes into a reader and other ones into a writer, is confusing
to our users. I think our ideal eventual solution is a single "grand
unified" Index class that efficiently does all things that IndexWriter
and IndexReader do today. (I think this is closest to your 2nd option
in that link).
I'm all for efficiency, but I'd be wary of a grand unifying class
combining Reader/Writer operations as you've already hit the nail on the
head that the reader/writers are too confusing, combining them, without
significant refactoring simplification sounds like it would just make
matters worse since they both already have a fair number of methods on
them. To me, we need to better define what a Reader does and what a
Writer does and make the appropriate changes to the APIs.
I agree: it's not clear how best to improve the confusion, short term
or long term.
I think the confusion indeed stems from the fact that IndexReader is
used to make certain changes (deletes, norms) and IndexWriter is used
for others (addDocuments, optimize, addIndices), and the fact that the
nearly ubiquitous use case of reindexing changed documents requires
one open IndexReader, do deletes, close (commit), open IndexWriter, do
adds, close (commit).
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.
Furthermore, if we did that, we can indeed simplify "explicit commits"
to mean "nothing is visible to readers until you close your writer".
This is the "commit only on close" idea that Doug suggested. With
this new approach there would be no added commit() method. And, a
writer would not write any segments_N (checkpoint) files until it is
closed.
I like this new implemenation for "explicit commits" better (thanks
everyone for the feedback!). I will work through this / think about
it more.
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
