XMLWordPrintable

Details

    • Bug
    • Status: Resolved
    • Major
    • Resolution: Fixed
    • 3.0.0-beta.3
    • 3.0.0-rc
    • None
    • None
    • 1
    • SDK11: Coll/Txn/Docs More Chip

    Description

      You get a NotSupportedError attempting to do a durable write on a 6.0 or earlier cluster. At least, when you use a DurabilityOptionBlock, in the scenarios_t.py tests. But, that used to be supported, just differently.

      We should maybe see if

      • we can be backwards-compatible (if LCB does somehow with maybe the old persistTo, replicateTo stuff?
      • we get bucketCapabilities when we open a bucket, and check before attempting the durable write. Perhaps logging something helpful or even raising a different exception?
      • maybe we can clever and convert (if there is a way) so the call is successful on a 6.0 cluster?

      I didn't have time to look into it while fixing the integration tests, so I skip durability on < 6.5 and this feels incomplete. So, lets look harder and make it better if possible.

      Attachments

        No reviews matched the request. Check your Options in the drop-down menu of this sections header.

        Activity

          david.kelly David Kelly added a comment -

          There is a seemingly unused ClientDurableOptionBlock. This, plus some conversion from the SDK3 DurabilityLevel - triggered by a call that checks the bucket's capabilities, seems like what we should do. We could simply check the capabilities once, cache that, and be efficient in doing this, while presenting one interface to the outside world.

          david.kelly David Kelly added a comment - There is a seemingly unused ClientDurableOptionBlock . This, plus some conversion from the SDK3 DurabilityLevel - triggered by a call that checks the bucket's capabilities, seems like what we should do. We could simply check the capabilities once, cache that, and be efficient in doing this, while presenting one interface to the outside world.
          david.kelly David Kelly added a comment -

          It could be that we only need to modify the tests, based on bucket capabilities, and give the older version of durability to < 6.5 and we work. Lets start there, and if so, our interface is fine and there is no issue. Moving to 3.0.0.rc as this should be verified in tests, so we are sure there is no interface issue.

          david.kelly David Kelly added a comment - It could be that we only need to modify the tests, based on bucket capabilities, and give the older version of durability to < 6.5 and we work. Lets start there, and if so, our interface is fine and there is no issue. Moving to 3.0.0.rc as this should be verified in tests , so we are sure there is no interface issue.
          david.kelly David Kelly added a comment -

          Turns out passing in a ClientDurability, in Scenarios.test_multi results in issues as well. The underpinnings of passing in a ClientDurability seem to fail – some issues the multi calls.

          But... It is more important to support < 6.5 for the actual RFC-spec'd stuff like upsert, insert, etc...

          So lets do 2 things:

          • fix scenarios to run on < 6.5, with minimal changes (since it is needing refactoring anyways)
          • add durability tests to collections_t.py so we are sure the most important calls are properly handling things

          This almost certainly doesn't effect the existing interface, but better to do this soon just to be sure.

          david.kelly David Kelly added a comment - Turns out passing in a ClientDurability, in Scenarios.test_multi results in issues as well. The underpinnings of passing in a ClientDurability seem to fail – some issues the multi calls. But... It is more important to support < 6.5 for the actual RFC-spec'd stuff like upsert, insert, etc... So lets do 2 things: fix scenarios to run on < 6.5, with minimal changes (since it is needing refactoring anyways) add durability tests to collections_t.py so we are sure the most important calls are properly handling things This almost certainly doesn't effect the existing interface, but better to do this soon just to be sure.
          david.kelly David Kelly added a comment -

          Ok – It seems like there are a few issues here. The persist_to and replicate_to were not being passed down in the multi calls, in most places. I corrected that, and now whenever the persist_to and/or replicate_to are not 0, I get a unsupported error. There are only those parameters being passed in – no durability_level, so I suspect the bindings have an issue.

          Similarly, a collection.upsert("key", "content", UpsertOptions(durability=ClientDurabliity(persistTo=PersistTo.One, replicateTo=ReplicateTo.One)) fails with same exception. So – my guess is the parameter handling for durability is at fault. A quick glance at the code showed no obvious issues.

          Since this really isn't an interface issue, and strictly a bug, we could postpone looking at this for a bit. Will put a limit on how hard I look before considering putting aside for other (maybe?) more pressing stuff.

          david.kelly David Kelly added a comment - Ok – It seems like there are a few issues here. The persist_to and replicate_to were not being passed down in the multi calls, in most places. I corrected that, and now whenever the persist_to and/or replicate_to are not 0, I get a unsupported error. There are only those parameters being passed in – no durability_level, so I suspect the bindings have an issue. Similarly, a collection.upsert("key", "content", UpsertOptions(durability=ClientDurabliity(persistTo=PersistTo.One, replicateTo=ReplicateTo.One)) fails with same exception. So – my guess is the parameter handling for durability is at fault. A quick glance at the code showed no obvious issues. Since this really isn't an interface issue, and strictly a bug, we could postpone looking at this for a bit. Will put a limit on how hard I look before considering putting aside for other (maybe?) more pressing stuff.
          david.kelly David Kelly added a comment -

          Note that lcb doesn't support a durable remove as well – if it is a client durable remove. There's a ticket for that CCBC-1199.

          So for now, I'll fixup the tests to not do that (noting that this is temporary, etc...), and make sure the bindings ignore it if it is passed in (and log as well). Then, when CCBC-1199 is handled, we can update accordingly.

          david.kelly David Kelly added a comment - Note that lcb doesn't support a durable remove as well – if it is a client durable remove. There's a ticket for that CCBC-1199 . So for now, I'll fixup the tests to not do that (noting that this is temporary, etc...), and make sure the bindings ignore it if it is passed in (and log as well). Then, when CCBC-1199 is handled, we can update accordingly.

          People

            david.kelly David Kelly
            david.kelly David Kelly
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Gerrit Reviews

                There are no open Gerrit changes

                PagerDuty