Doug Cutting wrote:
robert engels wrote:
I really wish Doug would comment on all of these proposed changes...
I wish he would too!
Ideally the segments file would only be updated when one commits, by
closing the index, or perhaps by calling a new method. So, if you
abort, all documents added since the last commit would not be indexed.
The advantage I see of adding a new method would be that one would save
the cost of creating a new writer, but creating writers is pretty cheap,
so I don't yet see an overwhelming mandate for a new method.
Remind me, why do we have to update the segments file except at close?
I'm sure there's a good reason, and that's central to this discussion.
It is sometimes nice to keep multiple versions of an index that share
much of their state. Today this is possible using 'cp -lr' and rsync on
unix, but it might be better if the APIs directly supported this sort of
thing. I think one can do this with a suitably clever Directory
implementation, so perhaps no API changes are required for this either.
We could indeed simply tie "close" to mean "commit now", and not add a
separate "commit" method.
But what about the "bulk delete then bulk add" case? Ideally if a
reader refreshes by checking "isCurrent()" it shouldn't ever open the
index "at a bad time". Ie, we need a way to open a reader, delete a
bunch of docs, close it *without* committing, open a writer, add a
bunch of docs, and then do the commit, all so that any readers that
are refreshing would know not to open the segments_N that was
committed with all the deletes but none of the adds. This is one use
case that explicit commits would address.
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
