Jason,
Is your need for IndexReader.clone entirely driven by needing a fast
way to swap in your own deleted docs?
Meaning, if you could plug in your own deleted docs to a reader
(somehow), would you not use clone anymore?
Mike
Jason Rutherglen wrote:
Hello,
In trying to figure out
Mike,
needing a fast way to swap in your own deleted docs?
Yes, however it is necessary to have a new IndexReader as well from a
reopened reader. So clone seems the best approach (unless there's a way
I'm not seeing). The clone
code is coming along, the norms test seems to pass. As long as
So it seems like a cloned reader would share everything with the
previous reader, but these rules would be enforced:
* If the old reader had pending changes (held the write lock) when
it was cloned, it 1) transfers the write lock to the clone, 2)
refuses any further changes to itself
ie snapshot the previous reader without going through disk as
intermediary, right?
Yes.
refuses any further changes to itself (freezes itself)
Should I create a new variable for refuse updates/freeze or use readonly?
If the variable is true then inside of doClose throw an exception? If
Jason Rutherglen wrote:
ie snapshot the previous reader without going through disk as
intermediary, right?
Yes.
refuses any further changes to itself (freezes itself)
Should I create a new variable for refuse updates/freeze or use
readonly? If the variable is true then inside of
On Tue, Dec 16, 2008 at 10:00 AM, Michael McCandless
luc...@mikemccandless.com wrote:
Is your need for IndexReader.clone entirely driven by needing a fast way to
swap in your own deleted docs?
Could this be done with a FilteredIndexReader subclass that keeps
track of additional deletions?
Hello,
In trying to figure out the best way to have a system for realtime whereby
the deletedDocs do not need to be saved there are two possible methods,
1) setting the DocIdBitSet manually (which breaks the saving and things,
but does not require doing norms cloning), or 2) implementing
