Details

      Description

      This is not playing nice.

        Activity

        Hide
        ASF subversion and git services added a comment -

        Commit 1613409 from Erik Hatcher in branch 'dev/branches/branch_4x'
        [ https://svn.apache.org/r1613409 ]

        SOLR-3622, SOLR-5847, SOLR-6194, SOLR-6269: Several DIH fixes/improvements (merged from r1613406)

        Show
        ASF subversion and git services added a comment - Commit 1613409 from Erik Hatcher in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1613409 ] SOLR-3622 , SOLR-5847 , SOLR-6194 , SOLR-6269 : Several DIH fixes/improvements (merged from r1613406)
        Hide
        ASF subversion and git services added a comment -

        Commit 1613406 from Erik Hatcher in branch 'dev/trunk'
        [ https://svn.apache.org/r1613406 ]

        SOLR-3622, SOLR-5847, SOLR-6194, SOLR-6269: Several DIH fixes/improvements

        Show
        ASF subversion and git services added a comment - Commit 1613406 from Erik Hatcher in branch 'dev/trunk' [ https://svn.apache.org/r1613406 ] SOLR-3622 , SOLR-5847 , SOLR-6194 , SOLR-6269 : Several DIH fixes/improvements
        Hide
        Erik Hatcher added a comment -

        I'm going to make an executive decision on this one and have it avoid any rollback call when in ZK mode, otherwise leave the behavior as-is (calls rollback if there's an error during full or delta import) in single-core mode.

        Show
        Erik Hatcher added a comment - I'm going to make an executive decision on this one and have it avoid any rollback call when in ZK mode, otherwise leave the behavior as-is (calls rollback if there's an error during full or delta import) in single-core mode.
        Hide
        Hoss Man added a comment -

        removing fixVersion=4.0 since there is no evidence that anyone is currently working on this issue. (this can certainly be revisited if volunteers step forward)

        Show
        Hoss Man added a comment - removing fixVersion=4.0 since there is no evidence that anyone is currently working on this issue. (this can certainly be revisited if volunteers step forward)
        Hide
        Robert Muir added a comment -

        rmuir20120906-bulk-40-change

        Show
        Robert Muir added a comment - rmuir20120906-bulk-40-change
        Hide
        Mark Miller added a comment -

        I don't mind if it's an option if you find it a useful feature. But we should be careful to doc it as not working with cloud at least.

        never rollback (default?)

        +1

        Show
        Mark Miller added a comment - I don't mind if it's an option if you find it a useful feature. But we should be careful to doc it as not working with cloud at least. never rollback (default?) +1
        Hide
        James Dyer added a comment -

        What if it was configurable so that users had 3 options:

        • rollback on failure (current option)
        • execute user-defined delete query on failure
        • never rollback (default?)
        Show
        James Dyer added a comment - What if it was configurable so that users had 3 options: rollback on failure (current option) execute user-defined delete query on failure never rollback (default?)
        Hide
        Yonik Seeley added a comment -

        Should the rollback feature be removed in favor of something more cloud-friendly?

        No. Some people do want it (same with the prepare). The uses are pretty special though, when you bave complete control of all updates going to Solr and you know exactly when commits happen, etc.

        In general, one should use something like deleteByQuery to remove a bunch of added updates (however that only works if the documents added are new and did not overwrite any older ones). Real transaction isolation is not a target feature for Solr.

        Show
        Yonik Seeley added a comment - Should the rollback feature be removed in favor of something more cloud-friendly? No. Some people do want it (same with the prepare). The uses are pretty special though, when you bave complete control of all updates going to Solr and you know exactly when commits happen, etc. In general, one should use something like deleteByQuery to remove a bunch of added updates (however that only works if the documents added are new and did not overwrite any older ones). Real transaction isolation is not a target feature for Solr.
        Hide
        Lance Norskog added a comment -

        rollback doesn't (and probably never will) have first-class cloud/distributed support

        Should the rollback feature be removed in favor of something more cloud-friendly?

        Show
        Lance Norskog added a comment - rollback doesn't (and probably never will) have first-class cloud/distributed support Should the rollback feature be removed in favor of something more cloud-friendly?
        Hide
        Yonik Seeley added a comment -

        +1
        rollback doesn't (and probably never will) have first-class cloud/distributed support, and it's also not nice to roll back other people's updates that were unrelated to DIH.

        Show
        Yonik Seeley added a comment - +1 rollback doesn't (and probably never will) have first-class cloud/distributed support, and it's also not nice to roll back other people's updates that were unrelated to DIH.

          People

          • Assignee:
            Erik Hatcher
            Reporter:
            Mark Miller
          • Votes:
            0 Vote for this issue
            Watchers:
            7 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development