hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Karthick Sankarachary (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HBASE-2960) Allow Incremental Table Alterations
Date Tue, 07 Dec 2010 19:28:13 GMT

    [ https://issues.apache.org/jira/browse/HBASE-2960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12968906#action_12968906
] 

Karthick Sankarachary commented on HBASE-2960:
----------------------------------------------

Thanks for making me a contributor! 

Just to clarify, this issue is not quite related to HBASE-2944. Whereas the latter is related
to the ALTER statement, it doesn't address the problem so eloquently described in http://mail-archives.apache.org/mod_mbox/hbase-user/201012.mbox/browser.
Basically, we want to superimpose (as opposed to overwrite) the schema specified in the ALTER
statement on top of the underlying schema. In short, the patch gets the column descriptor
from the admin object, and change only those properties of the column that were specified
in the ALTER statement. In other words, we don't try to default those properties *not* specified
in the ALTER statement.



> Allow Incremental Table Alterations
> -----------------------------------
>
>                 Key: HBASE-2960
>                 URL: https://issues.apache.org/jira/browse/HBASE-2960
>             Project: HBase
>          Issue Type: Wish
>          Components: client
>    Affects Versions: 0.89.20100621
>            Reporter: Karthick Sankarachary
>            Assignee: Karthick Sankarachary
>         Attachments: HBASE-2960.patch
>
>
> As per the HBase shell help, the alter command will "Alter column family schema;  pass
table name and a dictionary  specifying new column family schema." The assumption here seems
to be that the new column family schema must be completely specified. In other words, if a
certain attribute is not specified in the column family schema, then it is effectively defaulted.
Is this side-effect by design? 
> I for one assumed (wrongly apparently) that I can alter a table in "increments". Case
in point, the following commands should've resulted in the final value of the VERSIONS attribute
of my table to stay put at 1, but instead it got defaulted to 3. I guess there's no right
or wrong answer here, but what should alter do by default? My expectation is that it only
changes those attributes that were specified in the "alter" command, leaving the unspecified
attributes untouched.
> hbase(main):003:0> create 't1', {NAME => 'f1', VERSIONS => 1}
> 0 row(s) in 1.7230 seconds
> hbase(main):004:0> describe 't1'
> DESCRIPTION                                                            
>  {NAME => 't1', FAMILIES => [{NAME => 'f1', COMPRESSION => 'NONE', VERSIONS
=> '1', TTL => '2147483647', BLOCKSIZE => '65536', IN_MEMORY => ' false', BLOCKCACHE
=> 'true'}]}
> 1 row(s) in 0.2030 seconds
> hbase(main):006:0> disable 't1'
> 0 row(s) in 0.1140 seconds
> hbase(main):007:0> alter 't1', {NAME => 'f1', IN_MEMORY => 'true'}
> 0 row(s) in 0.0160 seconds
> hbase(main):009:0> describe 't1'
> DESCRIPTION                                                            
>  {NAME => 't1', FAMILIES => [{NAME => 'f1', VERSIONS => '3', COMPRESSION
=> 'NONE', TTL => '2147483647', BLOCKSIZE => '65536', IN_MEMORY => ' true', BLOCKCACHE
=> 'true'}]}
> 1 row(s) in 0.1280 seconds

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message