robert engels wrote:
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.
I agree this is a neat idea. But how would it actually work without
relying on specifics of filesystem behaviour when deleting open files?
Especially over NFS?
BTW, I do think we need to support NFS. It's ubiquitous (the default
remote filesystem) for Unix and so it's the obvious way to allow
readers to share an index. Our users automatically expect this should
work, and they're right. Likely performance will not be "stellar" but
for many apps that doesn't matter.
The point of LUCENE-710 (that started this discussion) is to fix
Lucene to not rely on the particular filesystem details of "deleting
open files" because NFS does not protect such files.
Doug's first suggestion ("commit on close") seems better to me.
First, we wouldn't have to make duplicated code in each Directory,
just once in IndexWriter. Second, it's a small change (no index format
change). Third, it can work over NFS so long as we relax how
aggressively IndexFileDeleter removes prior commits and we can ensure
readers correspondingly refresh.
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
