[
https://issues.apache.org/jira/browse/HBASE-7236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13508937#comment-13508937
]
Sergey Shelukhin commented on HBASE-7236:
-----------------------------------------
bq. 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?
Do you want to store them in the attributes dictionary though? Some attributes
are not config overrides (e.g. IS_ROOT/IS_META, in-memory, etc.), there are
also user attributes; above problems with having the same dictionary will
remain.
I can move the existing attributes into config overrides instead; some backward
compat might be necessary.
bq. 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?
The problem here is that you cannot have .add(List<A>) and .add(List<B>) due to
type erasure on generics. I will rename both methods to more elaborate,
semantically similar names.
> 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,
> HBASE-7236-PROTOTYPE-v1.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
