[
https://issues.apache.org/jira/browse/LUCENE-3464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13120014#comment-13120014
]
Uwe Schindler edited comment on LUCENE-3464 at 10/4/11 11:17 AM:
-----------------------------------------------------------------
This sophisticated backwards seems fine.
The most common use-case is:
One has a FilterIndexReader. All FilterIndexReaders should override reopen(),
as the reopened reader has to be wrapped, too. In that case the filter would
call super.reopen (or delegate.reopen), this would then trigger backwards.
IndexReader.openIfChanged() would also work on this filtered reader, as it
would detect the FilterIR to be old-style and would call its reopen method (so
the call chain would be: IR.openIfChanged(filter) -> filter.reopen() ->
wrappedReader.reopen() -> IR.openIfChanged(wrappedReader)) [wrappedReader is
new-style in this example]
I have to think about other use-cases, but the most common one seems to be fine.
was (Author: thetaphi):
This sophisticated backwards seems fine.
The most common use-case is:
One has a FilterIndexReader. All FilterIndexReaders should override reopen(),
as the reopened reader has to be wrapped, too. In that case the filter would
class super.reopen (or delegate.reopen), this would then trigger backwards.
IndexReader.openIfChanged() would also work on this filtered reader, as it
would detect the FilterIR to be old-style and would call its reopen method (so
the call chain would be: IR.openIfChanged(filter) -> filter.reopen() ->
wrappedReader.reopen() -> IR.openIfChanged(wrappedReader))
I have to think about other use-cases, but the most common one seems to be fine.
> Rename IndexReader.reopen to make it clear that reopen may not happen
> ---------------------------------------------------------------------
>
> Key: LUCENE-3464
> URL: https://issues.apache.org/jira/browse/LUCENE-3464
> Project: Lucene - Java
> Issue Type: Bug
> Reporter: Michael McCandless
> Assignee: Michael McCandless
> Fix For: 3.5, 4.0
>
> Attachments: LUCENE-3464.3x.patch, LUCENE-3464.patch,
> LUCENE-3464.patch
>
>
> Spinoff from LUCENE-3454 where Shai noted this inconsistency.
> IR.reopen sounds like an unconditional operation, which has trapped users in
> the past into always closing the old reader instead of only closing it if the
> returned reader is new.
> I think this hidden maybe-ness is trappy and we should rename it
> (maybeReopen? reopenIfNeeded?).
> In addition, instead of returning "this" when the reopen didn't happen, I
> think we should return null to enforce proper usage of the maybe-ness of this
> API.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
