[jira] Commented: (HBASE-2960) Allow Incremental Table Alterations
[
https://issues.apache.org/jira/browse/HBASE-2960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12968932#action_12968932
]
Karthick Sankarachary commented on HBASE-2960:
--
No, this issue does not exist in trunk - it has been addressed by HBASE-2984
already. Thanks.
> 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.
[jira] Commented: (HBASE-2960) Allow Incremental Table Alterations
[
https://issues.apache.org/jira/browse/HBASE-2960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12968925#action_12968925
]
stack commented on HBASE-2960:
--
bq. Thanks for making me a contributor!
No. Thank you for the sweet patches. Sorry we've been slow to get to them.
So, do we still have this issue in trunk? If so, I'll take the time to mess w/
your patch. Thanks.
> 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.
[jira] Commented: (HBASE-2960) Allow Incremental Table Alterations
[
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.
[jira] Commented: (HBASE-2960) Allow Incremental Table Alterations
[
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] Commented: (HBASE-2960) Allow Incremental Table Alterations
[
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.
