accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christopher Tubbs (JIRA)" <>
Subject [jira] [Commented] (ACCUMULO-2059) Namespace constraints easily get clobbered by table constraints
Date Fri, 24 Jan 2014 22:51:38 GMT


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:
>             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

View raw message