[
https://issues.apache.org/jira/browse/LUCENE-6524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14580543#comment-14580543
]
Robert Muir commented on LUCENE-6524:
-------------------------------------
Today, NRT readers already return an abstraction of IndexCommit (via
StandardDirectoryReader.getIndexCommit). And you can already pass IndexCommit
to IndexWriterConfig.setIndexCommit to tell IW to start from there. So I think
we just need to fix the NRT case?
Maybe its as simple as adding some package-private methods to IndexCommit, so
IW would "reuse" StandardDirectoryReader's ReaderCommit (somehow it would
return itself). We might need to think about how to force an incRef() too
up-front, because of reader pooling. It might be cleaner to move "get the
current fieldinfos" to this thing as well.
This would really clean up my concerns about the API and additional IW ctors.
Hopefully it would be simpler...
> Create an IndexWriter from an already opened NRT or non-NRT reader
> ------------------------------------------------------------------
>
> Key: LUCENE-6524
> URL: https://issues.apache.org/jira/browse/LUCENE-6524
> Project: Lucene - Core
> Issue Type: Improvement
> Reporter: Michael McCandless
> Assignee: Michael McCandless
> Fix For: 5.3, Trunk
>
> Attachments: LUCENE-6524.patch, LUCENE-6524.patch
>
>
> I'd like to add a new ctor to IndexWriter, letting you start from an already
> opened NRT or non-NRT DirectoryReader. I think this is a long missing
> API in Lucene today, and we've talked in the past about different ways
> to fix it e.g. factoring out a shared reader pool between writer and reader.
> One use-case, which I hit in LUCENE-5376: if you have a read-only
> index, so you've opened a non-NRT DirectoryReader to search it, and
> then you want to "upgrade" to a read/write index, we don't handle that
> very gracefully now because you are forced to open 2X the
> SegmentReaders.
> But with this API, IW populates its reader pool with the incoming
> SegmentReaders so they are shared on any subsequent NRT reopens /
> segment merging / deletes applying, etc.
> Another (more expert) use case is allowing rollback to an NRT-point.
> Today, you can only rollback to a commit point (segments_N). But an
> NRT reader also reflects a valid "point in time" view of the index (it
> just doesn't have a segments_N file, and its ref'd files are not
> fsync'd), so with this change you can close your old writer, open a
> new one from this NRT point, and revert all changes that had been done
> after the NRT reader was opened from the old writer.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
