lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Grant Ingersoll (JIRA)" <j...@apache.org>
Subject [jira] Commented: (LUCENE-1516) Integrate IndexReader with IndexWriter
Date Fri, 20 Feb 2009 17:57:01 GMT

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

Grant Ingersoll commented on LUCENE-1516:
-----------------------------------------

bq. Right, I'm just saying IndexAccessor will have many methods. And then
you're asking every app to make this switch, on upgrade. It's alot of
API swapping/noise vs a single added expert method to IW.

Sure, but that is already the case w/ IW/IR anyway.

I agree about the short term noise, but in the long run it seems cleaner.

bq. But this will be an expert/advanced API, a single added method to IW.
I wouldn't expect users to be confused: on upgrade I think most users
will not even notice its existence!

Hmm, I don't agree, but I guess it depends on the performance hit.  If given a choice between
the semantics of a reader that sees changes as they are made versus having to do the whole
reopen thing, I'm betting most users will say "duh, I want to see my changes right away" and
choose the IR that is synced w/ the IW, b/c that is what people think is the logical thing
to happen and it is how DBs work, which many devs. are used to.  As an app developer, if I
don't have to think about IR lifecycle management, why would I want to as long as it performs?
 What this patch is offering, AFAICT, is the removal of IR lifecycle managment from the user.

In other words, my guess is that over time, as the performance proves out, it will be the
default choice, not "expert".  Now, if you're telling me this is going to be significantly
slower even when updates are rare, then maybe I would stick to the current lifecycle, but
if there isn't much difference, I'll take the one that pushes the lifecycle complexity down
into Lucene instead of in my app.

> 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
>            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-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message