lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eks Dev (JIRA)" <>
Subject [jira] Commented: (LUCENE-2691) Consolidate Near Real Time and Reopen API semantics
Date Thu, 25 Nov 2010 14:45:14 GMT


Eks Dev commented on LUCENE-2691:

strictly speaking not really this issue, but somehow fits into discussion about  IR.reopen()

What would be the best way to support the following case? (Imo, very often needed. )

Directory d ="/path/to/somewhere"); // Nice
d_ram = RAMDirectory(d); 
r_ram =;  
r_ram.reload(); //Here we want to reload from the  FSDirecotory?

Point being, reload need not only IR/IW semantics consideration, but Directory as well.

Does this make sense?
A solution that looks doable would be to have "DiskBoundRAMDirectory extends RAMDirectory",
that would remain read-only and keep a reference to FSDirectory (or whatewer Directory). 
What is missing is a "signal" from IR.reload() to RAMdirectory to slurp fresh information
from FSDirecory? 


> Consolidate Near Real Time and Reopen API semantics
> ---------------------------------------------------
>                 Key: LUCENE-2691
>                 URL:
>             Project: Lucene - Java
>          Issue Type: Improvement
>            Reporter: Grant Ingersoll
>            Assignee: Grant Ingersoll
>            Priority: Minor
>             Fix For: 4.0
>         Attachments: LUCENE-2691.patch, LUCENE-2691.patch
> We should consolidate the IndexWriter.getReader and the IndexReader.reopen semantics,
since most people are already using the IR.reopen() method, we should simply add::
> {code}
> IR.reopen(IndexWriter)
> {code}
> Initially, it could just call the IW.getReader(), but it probably should switch to just
using package private methods for sharing the internals

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