Solr
  1. Solr
  2. SOLR-3347

deleteByQuery failing with SolrCloud without _version_ in schema.xml

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 4.0, 5.0
    • Component/s: SolrCloud
    • Labels:
      None

      Description

      Distributed execution of deleteByQuery("*:*") depends on the existence of a field _version_ in the schema. The default schema has no comment on this field to indicate its important or relevance to SolrCloud, and no message is logged nor error status returned when there is no such field. The code in DistributedUpdateProcessor just has an if statement that never ever does any local deleting without it.

      I don't know whether the intention was that this should work or not. If someone would clue me in, I'd make a patch for schema.xml to add comments, or a patch to D-U-P to add logging. If it was supposed to work, I'm probably not qualified to make the fix to make it work.

      1. solrconfig.xml
        56 kB
        Benson Margulies
      2. schema.xml
        7 kB
        Benson Margulies
      3. provision-and-start.sh
        1 kB
        Benson Margulies
      4. 0001-Attempt-to-repro-problem-with-del-and-SolrCloud.patch
        24 kB
        Benson Margulies

        Issue Links

          Activity

          Hide
          Benson Margulies added a comment -

          A patch as explained.

          Show
          Benson Margulies added a comment - A patch as explained.
          Hide
          Jan Høydahl added a comment -

          Benson, here are a few friendly suggestions for working with JIRA and patches (ref http://wiki.apache.org/solr/HowToContribute)

          Please use the JIRA "Comment" feature instead of editing the main description. The main description should be kept as a short problem description only, not involving solution...

          Also, any potential patch should be in SVN diff format from project root and named SOLR-NNNN.patch, i.e. SOLR-3347.patch. JIRA will keep track of which is the newest one.

          Show
          Jan Høydahl added a comment - Benson, here are a few friendly suggestions for working with JIRA and patches (ref http://wiki.apache.org/solr/HowToContribute ) Please use the JIRA "Comment" feature instead of editing the main description. The main description should be kept as a short problem description only, not involving solution... Also, any potential patch should be in SVN diff format from project root and named SOLR-NNNN.patch, i.e. SOLR-3347 .patch. JIRA will keep track of which is the newest one.
          Hide
          Benson Margulies added a comment -

          Jan Høydahl,

          I don't normally do radical edits to the description. However, in this particular case, my initial diagnostic theory was so wildly wrong that I felt it appropriate to either edit the description or close the JIRA and open a new one.

          As for the patch file names, that's just laziness. On the other hand, I'm one of the many people around the ASF making use of the git mirrors, especially when working on code where I'm not a committer – thus 'git format-patch'. You're the first person around here to express any problem with that. I wonder if there's some trick to get git to make a patch that is indistinguishable from svn diff.

          Show
          Benson Margulies added a comment - Jan Høydahl, I don't normally do radical edits to the description. However, in this particular case, my initial diagnostic theory was so wildly wrong that I felt it appropriate to either edit the description or close the JIRA and open a new one. As for the patch file names, that's just laziness. On the other hand, I'm one of the many people around the ASF making use of the git mirrors, especially when working on code where I'm not a committer – thus 'git format-patch'. You're the first person around here to express any problem with that. I wonder if there's some trick to get git to make a patch that is indistinguishable from svn diff.
          Hide
          Steve Rowe added a comment -

          git patches can be applied to svn checkouts with patch -p1, instead of the usual patch -p0 used with svn-generated patches.

          Show
          Steve Rowe added a comment - git patches can be applied to svn checkouts with patch -p1 , instead of the usual patch -p0 used with svn-generated patches.
          Hide
          Jan Høydahl added a comment -

          Cool, Steven, it worked well with -p1. I updated http://wiki.apache.org/solr/HowToContribute with this info.

          Show
          Jan Høydahl added a comment - Cool, Steven, it worked well with -p1. I updated http://wiki.apache.org/solr/HowToContribute with this info.
          Hide
          Hoss Man added a comment -

          bulk fixing the version info for 4.0-ALPHA and 4.0 all affected issues have "hoss20120711-bulk-40-change" in comment

          Show
          Hoss Man added a comment - bulk fixing the version info for 4.0-ALPHA and 4.0 all affected issues have "hoss20120711-bulk-40-change" in comment
          Hide
          Robert Muir added a comment -

          rmuir20120906-bulk-40-change

          Show
          Robert Muir added a comment - rmuir20120906-bulk-40-change
          Hide
          Hoss Man added a comment -

          As of SOLR-3745, SolrCloud will fail hard if you don't have _version_ in the schema.

          this can be relaxed if/when more fine grained pre-req checking is in place.

          Show
          Hoss Man added a comment - As of SOLR-3745 , SolrCloud will fail hard if you don't have _version_ in the schema. this can be relaxed if/when more fine grained pre-req checking is in place.
          Hide
          Hoss Man added a comment -

          I'm going to go ahead and resolve this as fixed since the new sanity checks in SolrCloud mode should prevent this situation from ever happening (see linked issue).

          Show
          Hoss Man added a comment - I'm going to go ahead and resolve this as fixed since the new sanity checks in SolrCloud mode should prevent this situation from ever happening (see linked issue).
          Hide
          Uwe Schindler added a comment -

          Closed after release.

          Show
          Uwe Schindler added a comment - Closed after release.

            People

            • Assignee:
              Hoss Man
              Reporter:
              Benson Margulies
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development