Lucene - Core
  1. Lucene - Core
  2. LUCENE-1551

Add reopen(IndexCommit) methods to IndexReader

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 2.9
    • Fix Version/s: 2.9
    • Component/s: core/index
    • Labels:
      None
    • Environment:

      Any

    • Lucene Fields:
      New

      Description

      Add reopen(IndexCommit) methods to IndexReader to be able to reopen an index on any previously saved commit points with all advantages of LUCENE-1483.

      Similar to open(IndexCommit) & company available in 2.4.0.

      1. LUCENE-1551.patch
        8 kB
        Michael McCandless

        Activity

        Hide
        Michael McCandless added a comment -

        I think reopen(IndexCommit) should always give you a readOnly reader?

        Show
        Michael McCandless added a comment - I think reopen(IndexCommit) should always give you a readOnly reader?
        Hide
        Michael McCandless added a comment -

        Attached patch. I plan to commit in a few days.

        Show
        Michael McCandless added a comment - Attached patch. I plan to commit in a few days.
        Hide
        Torin Danil added a comment -

        Since we moved delete to IndexWriter, I strongly feel that IndexReader SHOULD be always read-only,
        so your patch makes perfect sense to me.

        I know that there are still some operations that IndexWriter can't do, and real-time search needs them,
        so that's why LUCENE-1516 was created, right? But those guys don't need to open previous commit point,
        they need latest & greatest, so the patch should work for them too.

        But in the end (lucene4, or maybe sooner?), could it be possible to move all modifying methods
        to IndexWriter and let IndexReader to be what it says it is: a READER?

        Beside this totally random talk, the patch looks good, I'll try to test it in a day or two and let you know if there are any problems.

        Show
        Torin Danil added a comment - Since we moved delete to IndexWriter, I strongly feel that IndexReader SHOULD be always read-only, so your patch makes perfect sense to me. I know that there are still some operations that IndexWriter can't do, and real-time search needs them, so that's why LUCENE-1516 was created, right? But those guys don't need to open previous commit point, they need latest & greatest, so the patch should work for them too. But in the end (lucene4, or maybe sooner?), could it be possible to move all modifying methods to IndexWriter and let IndexReader to be what it says it is: a READER? Beside this totally random talk, the patch looks good, I'll try to test it in a day or two and let you know if there are any problems.
        Hide
        Michael McCandless added a comment -

        Since we moved delete to IndexWriter, I strongly feel that IndexReader SHOULD be always read-only,
        so your patch makes perfect sense to me.

        I agree...

        In 3.0, we are switching IndexReader.open to return a readOnly reader
        by default (it's now read/write).

        I know that there are still some operations that IndexWriter can't do, and real-time search needs them,
        so that's why LUCENE-1516 was created, right? But those guys don't need to open previous commit point,
        they need latest & greatest, so the patch should work for them too.

        Right, once realtime search is released, proves stable, etc.,
        IndexReader should no longer need any write operations (I think?).

        But in the end (lucene4, or maybe sooner?), could it be possible to move all modifying methods
        to IndexWriter and let IndexReader to be what it says it is: a READER?

        I think LUCENE-1516 won't land until after 3.0 (though, it's making
        fast progress now, so it could be we get initial version into 2.9).

        Then sometime in 3.x, we deprecate all write methods in IndexReader
        and add anything missing (setNorm, undeleteAll) into IndexWriter.

        Then in 4.x we would remove IndexReader's deprecated methods.

        Beside this totally random talk, the patch looks good, I'll try to test it in a day or two and let you know if there are any problems.

        Excellent, thanks – I'll hold off on committing until we hear back
        how your tests go!

        Show
        Michael McCandless added a comment - Since we moved delete to IndexWriter, I strongly feel that IndexReader SHOULD be always read-only, so your patch makes perfect sense to me. I agree... In 3.0, we are switching IndexReader.open to return a readOnly reader by default (it's now read/write). I know that there are still some operations that IndexWriter can't do, and real-time search needs them, so that's why LUCENE-1516 was created, right? But those guys don't need to open previous commit point, they need latest & greatest, so the patch should work for them too. Right, once realtime search is released, proves stable, etc., IndexReader should no longer need any write operations (I think?). But in the end (lucene4, or maybe sooner?), could it be possible to move all modifying methods to IndexWriter and let IndexReader to be what it says it is: a READER? I think LUCENE-1516 won't land until after 3.0 (though, it's making fast progress now, so it could be we get initial version into 2.9). Then sometime in 3.x, we deprecate all write methods in IndexReader and add anything missing (setNorm, undeleteAll) into IndexWriter. Then in 4.x we would remove IndexReader's deprecated methods. Beside this totally random talk, the patch looks good, I'll try to test it in a day or two and let you know if there are any problems. Excellent, thanks – I'll hold off on committing until we hear back how your tests go!
        Hide
        Michael McCandless added a comment -

        Torin have you had a chance to test this?

        Show
        Michael McCandless added a comment - Torin have you had a chance to test this?
        Hide
        Torin Danil added a comment -

        Yeah, sorry for delay.

        It worked just fine. If there are no objections, I'd say go ahead and commit.

        Show
        Torin Danil added a comment - Yeah, sorry for delay. It worked just fine. If there are no objections, I'd say go ahead and commit.
        Hide
        Michael McCandless added a comment -

        OK, thanks Torin. I just committed this!

        Show
        Michael McCandless added a comment - OK, thanks Torin. I just committed this!

          People

          • Assignee:
            Michael McCandless
            Reporter:
            Torin Danil
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development