lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Grant Ingersoll (JIRA)" <>
Subject [jira] Commented: (LUCENE-2691) Consolidate Near Real Time and Reopen API semantics
Date Wed, 13 Oct 2010 14:38:32 GMT


Grant Ingersoll commented on LUCENE-2691:

bq. The method you introduced makes it perfectly fine to open a reader on some directory,
and then try reopening it on IW, and then on another IW. Later you're going to add a heap
of guards on this method, and runtime exceptions if user does some pointless reopen sequence?

I don't see that.  All we did was move the call from IW to IR where the reopen method was
already located.  Nothing is preventing a user from doing exactly what you described above
with the old way either.

bq. What was wrong with old parameterless reopen() call?

Nothing.  That's why it is still there.  This is about user comprehension and usability of
the API, not about some functionality.  Having trained hundreds of people on this, it's confusing
to people (just like it's confusing that a "Reader" can do deletes).  Why would a Writer object
give me a Reader?  Why would a Reader do write functionality?  

bq. if you got a reader from IW, it reopens by asking said IW for the segments.

Yep, and if you (re)open a Reader with an IW you get a Reader based on those segments.

bq. Adding more ways to do the same thing in this case just seems to complicate the API. 

We didn't add any more ways to do this.  The exact same number of ways exist now.  All we've
done is kept Reader semantics on the Reader and Writer semantics on the Writer.  

> 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