[
https://issues.apache.org/jira/browse/HBASE-7236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13507920#comment-13507920
]
Andrew Purtell edited comment on HBASE-7236 at 12/1/12 10:28 AM:
-----------------------------------------------------------------
The per-CF settings/overrides are kept in the descriptor, which is the right
place for that IMO. The below are points I don't feel particularly strongly
about but think should be raised.
Rightly descriptor attribute convention is called out as sloppy. That should be
cleaned up. However I'm not sure adding the concept of "configuration override"
to either CompoundConfiguration or descriptor attributes is better.
Regards descriptor attributes, a "configuration override" is just another
attribute. Does it make sense to go in the other direction and fix where
descriptors have metadata which are configuration overrides with custom names,
meaning: rename them to the convention for Configuration? Otherwise now we have
not only attributes, some of which override settings in the XML configuration,
but now also "configuration overrides" that also do so?
Regards CompoundConfiguration, as an API user why should I care about tagging
if something I add to CompoundConfiguration is an 'override' or not. Seems any
.add() should simply override values added to the configuration by a previous
.add() ? Or are some overrides special that will continue to override values
even if they are provided in a subsequent .add(), so some of those values in
the .add() will override previous values from an earlier .add() as I would
expect but there are these other values changed with an .addOverride() that I
don't know about? Will an second addOverride override the previous addOverride
overrides? Confusing -- See?
was (Author: apurtell):
The per-CF settings/overrides are kept in the descriptor, which is the
right place for that IMO. The below are points I don't feel particularly
strongly about but think should be raised.
Rightly descriptor attribute convention is called out as sloppy. That should be
cleaned up. However I'm not sure adding the concept of "configuration override"
to either CompoundConfiguration or descriptor attributes is better.
Regards descriptor attributes, a "configuration override" is just another
attribute. Does it make sense to go in the other direction and fix where
descriptors have metadata which are configuration overrides with custom names,
meaning: rename them to the convention for Configuration? Otherwise now we have
not only attributes, some of which override settings in the XML configuration,
but now also "configuration overrides" that also do so?
Regards CompoundConfiguration, as an API user why should I care about tagging
if something I add to CompoundConfiguration is an 'override' or not. Seems any
.add() should simply override values added to the configuration by a previous
.add() ? Or are some overrides special that will continue to override values
even if they are provided in a subsequent .add(), so some of those values in
the .add() will continue to override previous values from an earlier .add() but
not .addOverride()? Will an second addOverride override the previous
addOverride overrides? And/or any configuration .add()ed in between -- See?
> add per-table/per-cf compaction configuration via metadata
> ----------------------------------------------------------
>
> Key: HBASE-7236
> URL: https://issues.apache.org/jira/browse/HBASE-7236
> Project: HBase
> Issue Type: New Feature
> Components: Compaction
> Affects Versions: 0.96.0
> Reporter: Sergey Shelukhin
> Assignee: Sergey Shelukhin
> Attachments: HBASE-7236-PROTOTYPE.patch, HBASE-7236-PROTOTYPE.patch
>
>
> Regardless of the compaction policy, it makes sense to have separate
> configuration for compactions for different tables and column families, as
> their access patterns and workloads can be different. In particular, for
> tiered compactions that are being ported from 0.89-fb branch it is necessary
> to have, to use it properly.
> We might want to add support for compaction configuration via metadata on
> table/cf.
--
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
