accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Josh Elser (JIRA)" <>
Subject [jira] [Commented] (ACCUMULO-1228) Allow clients to disable column families and locality groups
Date Thu, 04 Apr 2013 01:38:13 GMT


Josh Elser commented on ACCUMULO-1228:

I would *almost* go as far to say that I expect locality groups to be immutable. Granted,
I won't say that because that'd be an absurd requirement to make since we have no fixed column

[~kturner], your example begs the question "why did #3 happen?". I can understand where you're
coming from, but why did they change the definition of LG1 for a non-general use case? I would
argue that someone who re-defines a locality group in such a way that breaks client code,
the error is on the user. The system did exactly what was expected of it.

Let make a counter-argument: Say I create a table with specific Key sub-structure with custom
SKVIs that know how to parse the Key sub-structure. Some user comes along and adds some extra
Keys to the table which do not match the sub-structure to satisfy a new use case. My iterator
cannot parse the new Key and my SKVI throws an Exception.

I believe your concern is mitigated by having permissions/roles in place that would disallow
a user from re-defining a locality group without the proper authorization.
> Allow clients to disable column families and locality groups
> ------------------------------------------------------------
>                 Key: ACCUMULO-1228
>                 URL:
>             Project: Accumulo
>          Issue Type: New Feature
>          Components: client, tserver
>    Affects Versions: 1.5.0
>            Reporter: William Slacum
>            Priority: Minor
>             Fix For: 1.6.0
> There's an inconsistency between what a server is capable of and what a client can tell
it to do with respect to fetching column families.
> Currently, a user can tell a {{Scanner}} to fetch some set of column families. The iterators
support not only this, but also the converse where a user does not want to retrieve column
families. An iterator implementation can do this by hand, but a client cannot specifically
tell a Scanner to not return data from a set of column families. Clients should be able to
specify this option.
> There also seems to be an inconsistency with how locality groups are defined and then
utilized. If I want to specify a set of column families as being part of a locality group,
I have to provide a mapping of locality group name to a list of column families. If I want
to fetch a locality group, I have to get the mapping first, rather than just set which locality
group I want to use. It'd be more convenient to tell the scanner just to fetch which locality
groups I want, and have the server know which column families that means.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

View raw message