Uploaded image for project: 'Accumulo'
  1. Accumulo
  2. ACCUMULO-2059

Namespace constraints easily get clobbered by table constraints

    Details

    • Type: Bug
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: 1.6.0
    • Fix Version/s: 1.8.2, 2.0.0
    • Component/s: client
    • Labels:
      None

      Description

      This is why ShellServerIT#namespaces is failing currently. When you create a table with the default configurations, that includes a DefaultKeySizeConstraint at constraint.1. This overlaps the namespaces defined constraint.1, which is a NumericValueConstraint for the test.

      The issue is I'm not sure if this is accepted behavior or not. Constraint settings are already sorta wonky, but this is not the time to rewrite it. Before I fix it, I just need to know if that is tolerable behavior or if we want namespace constraints to start at a different value, like constraint.101 to minimize impact. Thoughts are requested.

        Issue Links

          Activity

          Hide
          mdrob Mike Drob added a comment -

          Christopher Tubbs - there was some discussion of dropping constraints from name-spaces entirely. Did that happen?

          Show
          mdrob Mike Drob added a comment - Christopher Tubbs - there was some discussion of dropping constraints from name-spaces entirely. Did that happen?
          Hide
          ctubbsii Christopher Tubbs added a comment -

          I don't recall that conversation, but no, it didn't happen. Constraints still apply to namespaces. This is still a current issue. I'm not sure if the behavior is tolerable or if we need to fix it, though.

          Show
          ctubbsii Christopher Tubbs added a comment - I don't recall that conversation, but no, it didn't happen. Constraints still apply to namespaces. This is still a current issue. I'm not sure if the behavior is tolerable or if we need to fix it, though.
          Hide
          ctubbsii Christopher Tubbs added a comment -

          Some options:

          1. Make constraint classname part of the key, not the value (this would also address some client-side race conditions on setting constraints that currently exist), and provide upgrade code.
          2. Provide a different 1-up sequence for namespaces "ns1, ns2, etc." to avoid collisions, and modify CreateNamespaceCommand to stop copying config from a table, as an initial template (or translate on copy, which is unintuitive).
          3. Ignore the issue.
          4. Explicitly read both namespace and table when using constraints, or provide a way to set the key that isn't a 1-up.
          Show
          ctubbsii Christopher Tubbs added a comment - Some options: Make constraint classname part of the key, not the value (this would also address some client-side race conditions on setting constraints that currently exist), and provide upgrade code. Provide a different 1-up sequence for namespaces "ns1, ns2, etc." to avoid collisions, and modify CreateNamespaceCommand to stop copying config from a table, as an initial template (or translate on copy, which is unintuitive). Ignore the issue. Explicitly read both namespace and table when using constraints, or provide a way to set the key that isn't a 1-up.
          Hide
          vines John Vines added a comment -

          It's not that different then the issue with system level constraints vs.
          Normal constraints. I'm thinking either disable or ignore for 1.6 and then
          this can be addressed by the other fix for that issue, which is to make
          their settings more like iterators.

          Sent from my phone, please pardon the typos and brevity.

          Show
          vines John Vines added a comment - It's not that different then the issue with system level constraints vs. Normal constraints. I'm thinking either disable or ignore for 1.6 and then this can be addressed by the other fix for that issue, which is to make their settings more like iterators. Sent from my phone, please pardon the typos and brevity.
          Hide
          ctubbsii Christopher Tubbs added a comment -

          I suppose it is true that it's not technically a new problem entirely, but namespaces do add more visibility to the feature. Perhaps we should just focus on the extra visibility namespaces add to this problem, rather than fix the hierarchy clobbering entirely, for 1.6.0?

          Show
          ctubbsii Christopher Tubbs added a comment - I suppose it is true that it's not technically a new problem entirely, but namespaces do add more visibility to the feature. Perhaps we should just focus on the extra visibility namespaces add to this problem, rather than fix the hierarchy clobbering entirely, for 1.6.0?
          Hide
          vines John Vines added a comment -

          How do you propose that? This is currently just a rehash of an existing problem that we decided to bump to 1.7, so I'm comfortable bumping this along as well.

          Show
          vines John Vines added a comment - How do you propose that? This is currently just a rehash of an existing problem that we decided to bump to 1.7, so I'm comfortable bumping this along as well.
          Hide
          ctubbsii Christopher Tubbs added a comment -

          I'm fine with bumping, especially if the best fix is to address the entire hierarchy as a whole.

          Show
          ctubbsii Christopher Tubbs added a comment - I'm fine with bumping, especially if the best fix is to address the entire hierarchy as a whole.

            People

            • Assignee:
              Unassigned
              Reporter:
              vines John Vines
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:

                Development