Lucene - Core
  1. Lucene - Core
  2. LUCENE-2887

Remove/deprecate IndexReader.undeleteAll

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 3.1, 4.0-ALPHA
    • Component/s: None
    • Labels:
      None
    • Lucene Fields:
      New

      Description

      This API is rather dangerous in that it's "best effort" since it can only un-delete docs that have not yet been merged away, or, dropped (as of LUCENE-2010).

      Given that it exposes impl details of how Lucene prunes deleted docs, I think we should remove this API.

      Are there legitimate use cases....?

        Activity

        Hide
        Andrzej Bialecki added a comment -

        The MultiPassIndexSplitter won't work without this API. It can be modified to use a subclass of IndexReader & term / postings enumerators to restore the current behavior, or it can be rewritten entirely as a (fabled) SinglePassIndexSplitter.

        Show
        Andrzej Bialecki added a comment - The MultiPassIndexSplitter won't work without this API. It can be modified to use a subclass of IndexReader & term / postings enumerators to restore the current behavior, or it can be rewritten entirely as a (fabled) SinglePassIndexSplitter.
        Hide
        Doron Cohen added a comment - - edited

        I think it is correct to say that "if the result of ir.numDeletedDocs() is N, then calling ir.undeleteAll() will undelete exactly N documents"... or am I missing it?

        Because if a merge was invoked for the segments seen by this reader, I see two options:

        1. A merge is on going, or the merge is done but uncommitted yet.
          This means that an index writer has a lock on the index, hence ir.undeleteAll() will fail to get the lock.
        2. The merge was already committed.
          This means that the index reader will fail to get write permission for being Stale.

        So I think this method behaves deterministically - perhaps its jdoc should say something like:
        Undeletes all #numDeletedDocs() documents currently marked as deleted in this index. ?

        Show
        Doron Cohen added a comment - - edited I think it is correct to say that "if the result of ir.numDeletedDocs() is N , then calling ir.undeleteAll() will undelete exactly N documents"... or am I missing it? Because if a merge was invoked for the segments seen by this reader, I see two options: A merge is on going, or the merge is done but uncommitted yet. This means that an index writer has a lock on the index, hence ir.undeleteAll() will fail to get the lock. The merge was already committed. This means that the index reader will fail to get write permission for being Stale. So I think this method behaves deterministically - perhaps its jdoc should say something like: Undeletes all #numDeletedDocs() documents currently marked as deleted in this index. ?
        Hide
        Michael McCandless added a comment -

        I think it is correct to say that "if the result of ir.numDeletedDocs() is N, then calling ir.undeleteAll() will undelete exactly N documents"... or am I missing it?

        That's right... it's just that you can no longer "rely" on how IW reclaims del docs.

        But I'll just commit that "clarification" to the javadoc and leave the API for now...

        Show
        Michael McCandless added a comment - I think it is correct to say that "if the result of ir.numDeletedDocs() is N, then calling ir.undeleteAll() will undelete exactly N documents"... or am I missing it? That's right... it's just that you can no longer "rely" on how IW reclaims del docs. But I'll just commit that "clarification" to the javadoc and leave the API for now...
        Hide
        Michael McCandless added a comment -

        I just sharpened the jdocs...

        Show
        Michael McCandless added a comment - I just sharpened the jdocs...
        Hide
        Grant Ingersoll added a comment -

        Bulk close for 3.1

        Show
        Grant Ingersoll added a comment - Bulk close for 3.1

          People

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

            Dates

            • Created:
              Updated:
              Resolved:

              Development