Thanks Mike, I'll dig around a bit and report back what I did.
20 aug 2007 kl. 14.33 skrev Michael McCandless:
"karl wettin" <[EMAIL PROTECTED]> wrote:
I want to set documents in my IndexReader as deleted, but I will
never commit these deletions. Sort of a filter on a reader rather
than on a searcher, and no write-locks.
Perhaps I can pass down a IndexDeletionPolicy to my IndexWriter that
ignores deletions from the IndexReader(s) to avoid the lock?
I don't think this will easily work. The IndexDeletionPolicy just has
control on which commits should be deleted. So if you open a reader,
do deletes, and close it, a new commit (segments_N+1) is created.
You could have your deletion policy at this point preserve the
previous commit, but then there's no way to tell IndexWriter on
opening the index to open the previous commit (it always opens the
most recent commit).
I guess if IndexWriter/IndexReader could open old commits, and if your
app could separately keep track of which commits should be ignored
(because they were from readers), then you could do it?
The problem is the reader will still write the commit into the
directory on close...
Changing the directory lock factory it will effect the IndexWriter
locks too? So that would not be an option, or?
Could you just use a NullLockFactory on the reader? This way when you
do deletes in the reader and it acquires a write lock it doesn't in
fact acquire the write lock (as seen by IndexWriter which would
presumably be using a "real" LockFactory)?
But, the reader will still write into the directory and stomp on any
IndexWriter that was also committing ....
I could go hacking in IndexReader, definalizing it for decoration of
deleteDocument(int), or something like that, but would really
prefere not to.
Yeah I think it may just be cleanest to modify IndexReader to not
acquire the write lock nor commit its changes to the Directory on
close.
This is for a transactional layer on top of Lucene, where I combine
the system index with a transactional index. Updated documents that
are represented in the transaction index must be filtered out from
the system index at IndexReader level without creating
write-locks. undeleteAll() would be an option if there was no locks
-- more than one transaction could be updating documents at the same
time.
Sounds wild!
Mike
---------------------------------------------------------------------
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]
