[
https://issues.apache.org/jira/browse/LUCENE-743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12534123
]
Hoss Man commented on LUCENE-743:
---------------------------------
in deciding "to clone or not clone" for the purposes of implementing reopen, it
may make sense to step back and ask a two broader questions...
1) what was the motivation for approaching reopen using clones in the first
place
2) what does it inherently mean to clone an indexreader.
the answer to the first question, as i understand it, relates to the issue of
indexreaders not being "read only" object ... operations can be taken which
modify the readers state, and those operations can be flushed to disk when the
reader is closed. so readerB = readerA.reopen(closeOld=false) and then
readerA.delete(...) is called, there is ambiguity as to what should happen in
readerB. so the clone route seems pretty straight forward if and only if we
have an unambiguous concept of cloning a reader (because then the clone
approach to reopen becomes unambiguous as well). alternately, since reopen is
a new method, we can resolve the ambiguity anyway we want, as long as it's
documented ... in theory we should pick a solution that seems to serve the most
benefit ... perhaps that solution is to document reopen with "if
reopen(closeOld=false) returns a new reader it will share state with the
current reader, attempting to do the following operations on this new reader
will result in undefined behavior"
the answer the the second is only important if we want to go the cloning route
... but it is pretty important in a larger sense then just reopening ... f we
start to say that any of the IndexReader classes are Clonable we have to be
very clear about what that means in *all* cases where someone might clone it in
addition to reopen ... in particular, i worry about what it means to clone a
reader which has already had "write" operations performed on it (something the
clone based version of reopen will never do because a write operation indicates
the reader must be current), but some client code might as soon as we add the
Clonable interface to a class.
> IndexReader.reopen()
> --------------------
>
> Key: LUCENE-743
> URL: https://issues.apache.org/jira/browse/LUCENE-743
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Index
> Reporter: Otis Gospodnetic
> Assignee: Michael Busch
> Priority: Minor
> Fix For: 2.3
>
> Attachments: IndexReaderUtils.java, lucene-743-take2.patch,
> lucene-743.patch, lucene-743.patch, lucene-743.patch, MyMultiReader.java,
> MySegmentReader.java, varient-no-isCloneSupported.BROKEN.patch
>
>
> This is Robert Engels' implementation of IndexReader.reopen() functionality,
> as a set of 3 new classes (this was easier for him to implement, but should
> probably be folded into the core, if this looks good).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
