You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "Karthick Sankarachary (JIRA)" <ji...@apache.org> on 2010/09/03 20:55:33 UTC
[jira] Created: (HBASE-2960) Allow Incremental Table Alterations
Allow Incremental Table Alterations
-----------------------------------
Key: HBASE-2960
URL: https://issues.apache.org/jira/browse/HBASE-2960
Project: HBase
Issue Type: Wish
Reporter: Karthick Sankarachary
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.
[jira] Commented: (HBASE-2960) Allow Incremental Table Alterations
Posted by "Karthick Sankarachary (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-2960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12907438#action_12907438 ]
Karthick Sankarachary commented on HBASE-2960:
----------------------------------------------
My bad. I unset the fix version for now.
> 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
> 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.
[jira] Updated: (HBASE-2960) Allow Incremental Table Alterations
Posted by "Karthick Sankarachary (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-2960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Karthick Sankarachary updated HBASE-2960:
-----------------------------------------
Status: Patch Available (was: Open)
> 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
> Fix For: 0.89.20100621
>
> 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.
[jira] Updated: (HBASE-2960) Allow Incremental Table Alterations
Posted by "Karthick Sankarachary (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-2960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Karthick Sankarachary updated HBASE-2960:
-----------------------------------------
Fix Version/s: (was: 0.89.20100621)
> 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
> 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.
[jira] Updated: (HBASE-2960) Allow Incremental Table Alterations
Posted by "Karthick Sankarachary (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-2960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Karthick Sankarachary updated HBASE-2960:
-----------------------------------------
Fix Version/s: 0.89.20100621
Affects Version/s: 0.89.20100621
Component/s: client
> 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
> Fix For: 0.89.20100621
>
>
> 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.
[jira] Commented: (HBASE-2960) Allow Incremental Table Alterations
Posted by "chenjiajun (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-2960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12906691#action_12906691 ]
chenjiajun commented on HBASE-2960:
-----------------------------------
this is the only issue of version 0.89.20100621?
when HBase 0.89.20100621 released ?
> 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
> Fix For: 0.89.20100621
>
> 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.
[jira] Updated: (HBASE-2960) Allow Incremental Table Alterations
Posted by "Karthick Sankarachary (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-2960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Karthick Sankarachary updated HBASE-2960:
-----------------------------------------
Attachment: HBASE-2960.patch
The initial patch is based on the $HBASE_HOME/bin/HBase.rb file. If the change makes sense, it would need to be applied to the src/main/ruby/hbase/admin.rb in trunk. In short, the change modifies the "alter" method so that it retrieves the column descriptor from the table, if it already exists, before applying the attributes passed to it.
> 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
> Fix For: 0.89.20100621
>
> 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.