Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Sat, 1 Dec 2012 10:29:58 +0000 (UTC)
From: "Andrew Purtell (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <344175699.48748.1354357798457.JavaMail.jiratomcat@arcas>
In-Reply-To: <401618139.36349.1354146719203.JavaMail.jiratomcat@arcas>
Subject: [jira] [Comment Edited] (HBASE-7236) add per-table/per-cf
 compaction configuration via metadata
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ 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