[
https://issues.apache.org/jira/browse/ACCUMULO-1228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13621657#comment-13621657
]
Josh Elser commented on ACCUMULO-1228:
--------------------------------------
bq. A possible driver for this change would be a new and important use case
for which a locality group change would be beneficial. But actually, they
probably would not have made the locality group config change because of fear
of breaking existing code. So the new use case would not benefit from
Accumulo's ability to change locality group config on the fly.
Someone is still making the conscious decision here to alter the locality
group. They could've made a new locality group instead of destroying the
original, no?
Actually, I'm a little fuzzy here. Say we have a table with columns [A,B,C,D,E]
and LG1=[A,B]. Say [[email protected]] makes LG2=[C,D]. Now [~kturner]
changes LG1 from [A,B] to [A,B,C]. Would my "column search space" for
specifying LG1 be [A,B,C,D] because of the overlap of LG1 and LG2? What happens
here after a compaction? Would LG1 and LG2 share a common "file" that contains
C or would LG1 "contain" all of LG2 and vice-versa because of the overlap? Am I
missing the joke here?
> 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
