[ 
https://issues.apache.org/jira/browse/LUCENE-1516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12675499#action_12675499
 ] 

Michael McCandless commented on LUCENE-1516:
--------------------------------------------

bq. I guess it depends on the performance hit.

It's challenging to implement truly live updates w/ decent
performance: I think we'd need to build the reader impl that can
search DocumentsWriter buffer.

Whereas the approach (patch) here is actually quite simple (all the
hard work was already done -- IndexReader.reopen,
collection/sorting/filtering by segment, etc.).

bq. In other words, my guess is that over time, as the performance proves out, 
it will be the default choice, not "expert".

I agree: realtime search will likely be a popular feature once we
finish it, release it, it proves stable, performant, etc.  Eventually
(maybe soon) it should be made the default.

I think IndexAccessor makes alot of sense, but it's a big change and
I'd rather not couple it to this issue.  There are many questions to
be hashed out (under a new issue): is it a simple pass-through?  Or
does it manage the lifecycle of the readers for you?  Does it warm new
readers?  Should it emulate "live" update semantics?  Should getReader
get it from the writer if there is one (ie, making realtime search the
"default")?  Etc.


> 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
>
>   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

Reply via email to