accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christopher Tubbs (JIRA)" <>
Subject [jira] [Commented] (ACCUMULO-3122) Rename per-table custom tag property prefix
Date Sun, 14 Sep 2014 21:26:33 GMT


Christopher Tubbs commented on ACCUMULO-3122:

bq. this is just providing some "standard" convention to say "put all your properties 'here'".

Well, yeah, that's a fair assessment of this feature. I wouldn't want them putting these in
with a {{table.iterator}} prefix, or in some other place reserved for something else. That
could be quite confusing, and it's risky, because it's not always clear how the system will
respond to seeing such things (will the server misinterpret something and try to instantiate
a class, resulting in ClassNotFoundException?, etc.), so there's a good reason to have a dedicated
safe area. But you're right... this is all it is... just a convenience, not a fundamentally
empowering feature.

So long as it is provided, though, it has to have *some* name... not a special one... just
something we can use to clearly convey that it's just a convenient location for custom properties.
Right now, the best way to describe it, based on the property key/name would probably be "user-defined
custom per-table properties for tables and namespaces". But, "tag" might be just as informative,
and it has obvious advantages for brevity.

> Rename per-table custom tag property prefix
> -------------------------------------------
>                 Key: ACCUMULO-3122
>                 URL:
>             Project: Accumulo
>          Issue Type: Sub-task
>          Components: client
>            Reporter: Christopher Tubbs
>            Priority: Trivial
>              Labels: api, docuentation, naming
>             Fix For: 1.7.0
> I'm not 100% sold on the name of the {{table.custom.\*}} prefix added in ACCUMULO-2841.
I think a better name might be {{table.tag.\*}} or similar, and I'm leaning towards that.
*Tag* might be better vocabulary to use, especially when discussing the feature in the documentation,
and the property prefix name should be consistent with how we refer to the feature.
> I'm creating this issue to provide a forum for property name suggestions/informal votes/comments,
so the name can be solidified before the feature manifests in a release. I don't want to change
it to *tag* now, and then tomorrow change it again in favor of a better name.

This message was sent by Atlassian JIRA

View raw message