accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christopher Tubbs (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ACCUMULO-2841) Arbitrary namespace and table metadata tags
Date Sun, 14 Sep 2014 04:02:33 GMT

    [ 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)

Mime
View raw message