[
https://issues.apache.org/jira/browse/LUCENE-1516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12675979#action_12675979
]
Jason Rutherglen commented on LUCENE-1516:
------------------------------------------
> make a new SegmentReaderPool private class
I'd prefer the SegmentReaderPool model over the patch's existing one
as it is simpler and closer to how the underlying system actually
works meaning it works directly with the segments in a systematized way.
> We would never mergeSegmentInfos, never ask the "internal reader"
to commit
Good, merging the segmentInfos is confusing and tricky to debug
> Since IndexReader will always be readonly, you can simplify the new
DirectoryIndexReader.open method
+1
> why we need merge.segmentReadersClone?
I was modeling after the segmentInfosClone. If it's not necessary
I'll happily remove it.
> I think the only reason for reader to hold a reference to writer is
so that on reopen, the reader realizes it was created from
IW.getReader and simply forwards the request to IW
+1
> Wouldn't delete-by-Query cover this? Ie one could always make a
Filter implementing the "look @ field cache, do some logic, provide
docIDs to delete", wrap as Query, then delete-by-Query? (from a
previous coment)
Yes that will work.
How are these sample SegmentReaderPool method signatures?
{code}
private class SegmentReaderPool {
public SegmentReader get(SegmentInfo si) {}
public void decRef(SegmentReader sr) {}
}
{code}
> 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
> Assignee: Michael McCandless
> 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, 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
