[
https://issues.apache.org/jira/browse/ACCUMULO-2841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14133071#comment-14133071
]
Christopher Tubbs commented on ACCUMULO-2841:
---------------------------------------------
[~vines]: Yes, I can, and I would have had I recognized it to be the case that
the patch only provided a subset. However, I did not interpret the work done to
be a subset of the requested features, since I requested them, and all my
expectations were satisfied. If they had not been, I would have commented
accordingly on Jenna's pull request.
There was only one other commenter (you), who I could have had any reasonable
suspicion of having different expectations, but I did not interpret your
comment back in June (phrased as *I'm wondering if we should...*), to represent
a blocker or requirement for this issue, especially since you did not follow up
in comments later about the original idea being metadata-oriented (which would
have made your suggestion much, much, harder). That is the only feature I can
imagine you mean was omitted, when you say "subset".
I did, just now, create ACCUMULO-3121, in regards to your comment. While I
didn't consider it within scope of the original identified issue here, I liked
it enough to support a ZK solution to this issue so that future work could be
done if somebody were interested in creating a ticket and pursuing that.
However, I wouldn't have thought it to be my specific responsibility to create
that issue just because the issue in which it was mentioned was closed by me,
as you've implied. Anybody interested in that feature could have done that, but
I've created it as requested, regardless. Since it was me, I hope the wording
accurately represents your intentions/expectations for that follow-on work
(because I didn't/can't know precisely what you had in mind when you first
speculated about it in the comments above).
Regarding namespace and permissions testing, all per-table config already works
for namespaces, and that's tested separately, as well as tests for permissions
to set properties. Those tests continue to pass after this patch. Because the
implementation was a minor extension to an existing feature, in which those
things are already tested, I thought the patch's provided test, which is more
narrowly scoped to testing the provided change set, was sufficient. Had the
implementation been a different one, in which those additional requirements
were provided by a new mechanism, certainly, I'd have required tests for those
new mechanisms before signing off on the patch.
This brings up an interesting question: *is a patch for a new feature, which
leverages existing features, expected to test the existing features because it
relies on them to satisfy the new feature's requirements?* If the answer is
"yes, always", it seems we could spend a lot of time writing redundant tests,
which don't provide any additional meaningful code coverage. I think the answer
is probably "sometimes", and I'd probably lean towards testing those existing
features when they are used in a complex way, not covered by the existing test
suite for those old features. I don't think that's the case here, though. This
new feature isn't complex and doesn't change anything with regard to per-table
configuration permissions or the use of per-table configuration items in
namespace configs. Those features already are tested and work in the general
case (regardless of which property is being set), so they should work in this
case, also (setting a property with this new prefix).
I don't think any additional tests for this are essential. If you still feel
those additional tests are necessary, could you please create a sub-task,
though?
> Arbitrary namespace and table metadata tags
> -------------------------------------------
>
> Key: ACCUMULO-2841
> URL: https://issues.apache.org/jira/browse/ACCUMULO-2841
> Project: Accumulo
> Issue Type: New Feature
> Components: client
> Reporter: Christopher Tubbs
> Assignee: Jenna Huston
> Labels: metadata, newbie
> Fix For: 1.7.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Application-level tags (tagName = tagValue) could be added to tables and
> namespaces, to allow applications to set application-level metadata about a
> namespace or table.
> Use cases include management for billing, administrator notes, date created,
> last ingest time, stats, information about the table's schema... or anything
> else an application might wish to use tags for.
> These tags could be stored in zookeeper, but are probably best stored in the
> metadata table (probably in a separate reserved area of the metadata table,
> ~tag) because they could be arbitrarily large and do not need to be persisted
> in memory.
> This feature would include new APIs to manipulate table / namespace metadata.
> Considerations should be made to ensure users have appropriate permissions to
> add tags to an object.
> This feature could be used to implement ACCUMULO-650.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
