1. Solr
  2. SOLR-5374

Support user configured doc-centric versioning rules


    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 4.6, Trunk
    • Component/s: None
    • Labels:


      The existing optimistic concurrency features of Solr can be very handy for ensuring that you are only updating/replacing the version of the doc you think you are updating/replacing, w/o the risk of someone else adding/removing the doc in the mean time – but I've recently encountered some situations where I really wanted to be able to let the client specify an arbitrary version, on a per document basis, (ie: generated by an external system, or perhaps a timestamp of when a file was last modified) and ensure that the corresponding document update was processed only if the "new" version is greater then the "old" version – w/o needing to check exactly which version is currently in Solr. (ie: If a client wants to index version 101 of a doc, that update should fail if version 102 is already in the index, but succeed if the currently indexed version is 99 – w/o the client needing to ask Solr what the current version)

      The idea Yonik brought up in SOLR-5298 (letting the client specify a _new_version_ that would be used by the existing optimistic concurrency code to control the assignment of the _version_ field for documents) looked like a good direction to go – but after digging into the way _version_ is used internally I realized it requires a uniqueness constraint across all update commands, that would make it impossible to allow multiple independent documents to have the same _version_.

      So instead I've tackled the problem in a different way, using an UpdateProcessor that is configured with user defined field to track a "DocBasedVersion" and uses the RTG logic to figure out if the update is allowed.

      1. SOLR-5374.patch
        11 kB
        Yonik Seeley
      2. SOLR-5374.patch
        70 kB
        Yonik Seeley
      3. SOLR-5374.patch
        55 kB
        Yonik Seeley
      4. SOLR-5374.patch
        36 kB
        Yonik Seeley
      5. SOLR-5374.patch
        39 kB
        Hoss Man
      6. SOLR-5374.patch
        36 kB
        Hoss Man

        Issue Links


          Hoss Man created issue -
          Hoss Man made changes -
          Field Original Value New Value
          Attachment SOLR-5374.patch [ 12609543 ]
          Hoss Man made changes -
          Link This issue relates to SOLR-5298 [ SOLR-5298 ]
          Hoss Man made changes -
          Attachment SOLR-5374.patch [ 12610192 ]
          Yonik Seeley made changes -
          Link This issue depends upon SOLR-5395 [ SOLR-5395 ]
          Yonik Seeley made changes -
          Attachment SOLR-5374.patch [ 12610708 ]
          Yonik Seeley made changes -
          Link This issue depends upon SOLR-5406 [ SOLR-5406 ]
          Yonik Seeley made changes -
          Attachment SOLR-5374.patch [ 12611393 ]
          Yonik Seeley made changes -
          Attachment SOLR-5374.patch [ 12611449 ]
          Yonik Seeley made changes -
          Status Open [ 1 ] Resolved [ 5 ]
          Fix Version/s 4.6 [ 12325000 ]
          Fix Version/s 5.0 [ 12321664 ]
          Resolution Fixed [ 1 ]
          Yonik Seeley made changes -
          Attachment SOLR-5374.patch [ 12612994 ]


            • Assignee:
              Hoss Man
              Hoss Man
            • Votes:
              0 Vote for this issue
              8 Start watching this issue


              • Created: