[
https://issues.apache.org/jira/browse/ACCUMULO-2059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13881509#comment-13881509
]
Christopher Tubbs commented on ACCUMULO-2059:
---------------------------------------------
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.
> Namespace constraints easily get clobbered by table constraints
> ---------------------------------------------------------------
>
> Key: ACCUMULO-2059
> URL: https://issues.apache.org/jira/browse/ACCUMULO-2059
> Project: Accumulo
> Issue Type: Bug
> Components: client
> Reporter: John Vines
> Fix For: 1.6.0
>
>
> 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.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
