[
https://issues.apache.org/jira/browse/LUCENE-1516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12675394#action_12675394
]
Michael McCandless commented on LUCENE-1516:
--------------------------------------------
{quote}
maybe we don't need all those variants? String, File and Directory are all
easily enough collapsed down to just Directory.
{code}
new IndexWriter(new Directory(indexFile));
{code}
{quote}
(You'd presumably need to close that Directory). But, yeah, we may be
able to drop some of them, although I do think they are convenient for
new users of Lucene. And forcing users to switch to a totally new yet
pass through API on ugprade, but not giving them one to one carryover,
is not very nice.
bq. Additionally, there are no more variants than there already are on the IW
and IR, right?
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.
{quote}
As for pass-through or not, I think it would just pass-through, at
least initially, but it certainly leaves open the possibility for
reference counting in the future if someone wants to implement that.
{quote}
If we think it'll be more than just pass through, we should try to
hash out, somewhat, what it will & won't do up front (changing it
later is a big change)? And we should start from LUCENE-390.
{quote}
As someone who teaches people these APIs on a regular basis, I feel
pretty confident in saying that adding an IR to the IW as a public API
is going to confuse a good chunk of people just as the delete stuff on
the IR currently does now.
{quote}
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!
bq. You wouldn't ask FileWriter for a FileReader, would you?
I'm not sure that's the right comparison -- Lucene's IW does far more
than a FileWriter. And the fact that Lucene allows "point in time"
searching (which is very useful and rather unique) is a very big
difference vs FileReader/Writer.
{quote}
Likewise, isn't it just as logical to ask for an IW from an IR?
{quote}
I don't think so: the functionality is not symmetric, because Lucene
allows only one writer open at a time, but many readers (eg on
different commits). Since a writer is the one making changes, it
makes sense that you'd ask it, right now, to give you a reader
reflecting all changes up to that point. And call it again later to
get a reader seeing changes after that, 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
> 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
>
> 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
