accumulo-notifications mailing list archives

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

    [ https://issues.apache.org/jira/browse/ACCUMULO-1228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13621637#comment-13621637
] 

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
scheme.

[~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: https://issues.apache.org/jira/browse/ACCUMULO-1228
>             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: http://www.atlassian.com/software/jira

Mime
View raw message