lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael McCandless (JIRA)" <>
Subject [jira] Commented: (LUCENE-1589) IndexWriter.addIndexesNoOptimize(IndexReader[] readers)
Date Wed, 08 Apr 2009 12:41:13 GMT


Michael McCandless commented on LUCENE-1589:

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?

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:
>             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:
For additional commands, e-mail:

View raw message