Uploaded image for project: 'Solr'
  1. Solr
  2. SOLR-3998

Atomic update on uniqueKey field itself causes duplicate document

        Details

        • Type: Bug
        • Status: Closed
        • Priority: Major
        • Resolution: Fixed
        • Affects Version/s: 4.0
        • Fix Version/s: 4.1
        • Component/s: None
        • Labels:
          None
        • Environment:

          Windows XP and RH Linux

          Description

          Issuing an atomic update which includes the uniqueKey field itself will cause Solr to insert a second document with the same uniqueKey thereby violating uniqueness. A non-atomic update will "correct" the document. Attached is a JUnit test case that demonstrates the issue against the collection1 core in the standard Solr download.

            Activity

            Descending order - Click to sort in ascending order
            Hide
            Permalink
            commit-tag-bot Commit Tag Bot added a comment -

            [branch_4x commit] Yonik Seeley
            http://svn.apache.org/viewvc?view=revision&revision=1402743

            SOLR-3998: Atomic update on uniqueKey field itself causes duplicate document

            Show
            commit-tag-bot Commit Tag Bot added a comment - [branch_4x commit] Yonik Seeley http://svn.apache.org/viewvc?view=revision&revision=1402743 SOLR-3998 : Atomic update on uniqueKey field itself causes duplicate document
            Hide
            Permalink
            yseeley@gmail.com Yonik Seeley added a comment -

            Fix committed to trunk & 4x.

            Show
            yseeley@gmail.com Yonik Seeley added a comment - Fix committed to trunk & 4x.
            Hide
            Permalink
            yseeley@gmail.com Yonik Seeley added a comment -

            Thanks Eric - I've changed UpdateTest to include this scenario and replicated what you see.
            I think the right thing to do here is probably throw an exception (rather than ignore the modifiers on the id field).

            Show
            yseeley@gmail.com Yonik Seeley added a comment - Thanks Eric - I've changed UpdateTest to include this scenario and replicated what you see. I think the right thing to do here is probably throw an exception (rather than ignore the modifiers on the id field).
            Hide
            Permalink
            espencer703 Eric Spencer added a comment -

            Obviously, the workaround is to make sure that you don't do an atomic update on the uniqueKey field itself (which I was sort of doing by accident anyway). I just don't think anything should allow the violating of the uniqueKey.

            Show
            espencer703 Eric Spencer added a comment - Obviously, the workaround is to make sure that you don't do an atomic update on the uniqueKey field itself (which I was sort of doing by accident anyway). I just don't think anything should allow the violating of the uniqueKey.
            Hide
            Permalink
            espencer703 Eric Spencer added a comment -

            JUnit 4 test case demonstrating the problem.

            Show
            espencer703 Eric Spencer added a comment - JUnit 4 test case demonstrating the problem.

              People

              • Assignee:
                yseeley@gmail.com Yonik Seeley
                Reporter:
                espencer703 Eric Spencer
              • Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Development