[ https://issues.apache.org/jira/browse/LUCENE-1589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12697001#action_12697001 ]
Michael McCandless commented on LUCENE-1589: -------------------------------------------- {quote} The deletes are coming into the existing IndexReaders, then we do the IW.commitMergedDeletes styled copy of new deletes into the newly merged readers. Are there caveats? {quote} I'm now thinking that we should do all of this, internally to IW, under the hood, when it's doing NRT (as part of LUCENE-1313). Ie, we should not expose an external addIndexes API that must deal with ongoing deletes arriving to the IndexReaders you had passed in. I think it's useful to expose such an API, with the restriction that you should not be modifying those IR's (deletes, norms) while addIndexes is running. Ie, that method would be just like the addIndexes(IndexReader[]) we have today, but it'd have the same benefits of addIndexesNoOptimize. > IndexWriter.addIndexesNoOptimize(IndexReader[] readers) > ------------------------------------------------------- > > Key: LUCENE-1589 > URL: https://issues.apache.org/jira/browse/LUCENE-1589 > Project: Lucene - Java > Issue Type: Improvement > Components: Index > Affects Versions: 2.4.1 > Reporter: Jason Rutherglen > Priority: Minor > Fix For: 2.9 > > Original Estimate: 168h > Remaining Estimate: 168h > > Similar to IndexWriter.addIndexesNoOptimize(Directory[] dirs) > but for IndexReaders. This will be used to flush cloned ram > indexes to disk for near realtime indexing. -- 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