Doug Cutting wrote:
Michael McCandless wrote:
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.
One could also implement this with a Directory that permits
checkpointing and rollback. Would that be any simpler?
True (I think?). Maybe we could push the "transactional" behavior
down lower (into Directory) in Lucene. Though all implementations of
Directory would need to implement their own transactional behavior vs
one implementation at the reader/writer layer?
As long as checkpointing is decoupled from the opening/closing of
readers and writers then I think this would support this use case.
So basically, the Directory layer would "mimic" the inode model (and
hard links) that unix filesystems provide? Or maybe the Directory
would not make any changes visible to a reader until a writer did a
"checkpoint"? But then how would this work across machines (on a
shared filesystem)? I'm not sure I see how we could effectively (or
more simply) push this down into Directory instead of at the
reader/writer layer.
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
