[
https://issues.apache.org/jira/browse/LUCENE-743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12535753
]
Michael Busch commented on LUCENE-743:
--------------------------------------
{quote}
How about just defining the behavior such that any pending changes are flushed.
That would make it more useful because you could then reopen readers you used
for deletes.
{quote}
Hmm, I'm not sure I understand. A reader which is being used for deletes or
setting norms is always current (it owns the write lock), so there should never
be the need to re-open such a reader.
However, if you re-open an existing reader which was not used for deletes
before and use the new instance (b) to perform deletes, it will result in a
undefined behavior for the old reader (a):
{code:java}
IndexReader a = .....
....
IndexReader b = a.reopen();
b.deleteDocument(...);
{code}
> 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]
