In thinking about this some more, I think Doug's idea of doing this
in a directory implementation has a lot of merit.
It probably requires a few new methods to the Directory class, but in
all (almost?) cases they should be able to be no-ops.
I think the end result is that the code might be a lot cleaner,
easier to understand in the simple case, and easier to maintain
backwards compatibility, especially for those Lucene users that
already have layers around the the low-level classes.
Something akin to : you open the reader for a using a directory
created at a point in time, and it manages what version of files the
Reader sees.
I think it would also need commit() and rollback(), statements for
those directories that support transactions.
On Jan 17, 2007, at 1:52 PM, Marvin Humphrey wrote:
On Jan 17, 2007, at 6:30 AM, Michael McCandless wrote:
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)?
+1 (: advisory vote :)
KinoSearch, too.
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).
'zactly.
Marvin Humphrey
Rectangular Research
http://www.rectangular.com/
---------------------------------------------------------------------
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]
