[
https://issues.apache.org/jira/browse/LUCENE-1516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12675349#action_12675349
]
Michael McCandless commented on LUCENE-1516:
--------------------------------------------
bq. I suppose if I know I'm not going to be changing my index, I can still just
get a read-only IR, right?
Right, I think we still want to allow opening a standalone (uncoupled)
reader.
bq. Then, everyone has a single point of entry for both writers and readers and
all of this stuff can just be done through package private methods on the IW
and it allows us to change things if we decide otherwise and it means that the
IW is not coupled with the IR publicly.
I'm torn... the IndexAccessor would need to expose many variants to
carry over all the options we now have (String or File or Directory,
IndexCommit or not, IndexDeletionPolicy or not, create or not). It
will end up exposing a number of new methods... and, would it try to
be "smart" (like IndexModifier, and the LuceneIndexAccessor class in
LUCENE-390), keeping track of references to the readers it's handed
out, etc.? Or is it simply a pass-through to the underlying
open/ctors we have today?
The alternative (as of right now, unless we are missing something
further with these changes) is adding one method to IndexWriter,
getReader, that returns a readOnly IndexReader, "coupled" to the
writer you got it from in that it's able to search un-committed
changes and if you reopen it, writer will materialize all changes and
make them visible to the reopened reader.
I guess so far I don't really see why this small (one method) API
change merits a switch to a whole new accessor API for creating
readers & writers on an index? Maybe there is a
straw-that-breaks-the-camel's-back argument that I'm missing...
> Integrate IndexReader with IndexWriter
> ---------------------------------------
>
> Key: LUCENE-1516
> URL: https://issues.apache.org/jira/browse/LUCENE-1516
> Project: Lucene - Java
> Issue Type: Improvement
> Affects Versions: 2.4
> Reporter: Jason Rutherglen
> Priority: Minor
> Fix For: 2.9
>
> Attachments: LUCENE-1516.patch, LUCENE-1516.patch, LUCENE-1516.patch,
> LUCENE-1516.patch, LUCENE-1516.patch, LUCENE-1516.patch
>
> Original Estimate: 672h
> Remaining Estimate: 672h
>
> The current problem is an IndexReader and IndexWriter cannot be open
> at the same time and perform updates as they both require a write
> lock to the index. While methods such as IW.deleteDocuments enables
> deleting from IW, methods such as IR.deleteDocument(int doc) and
> norms updating are not available from IW. This limits the
> capabilities of performing updates to the index dynamically or in
> realtime without closing the IW and opening an IR, deleting or
> updating norms, flushing, then opening the IW again, a process which
> can be detrimental to realtime updates.
> This patch will expose an IndexWriter.getReader method that returns
> the currently flushed state of the index as a class that implements
> IndexReader. The new IR implementation will differ from existing IR
> implementations such as MultiSegmentReader in that flushing will
> synchronize updates with IW in part by sharing the write lock. All
> methods of IR will be usable including reopen and clone.
--
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: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
