BTW, I'm using version phoenix-4.7.0.2.5.0.0-1245
On Fri, Jun 9, 2017 at 12:58 PM, Michael Young <yomaiq...@gmail.com> wrote:
> Thanks, Ankit!
>
> I have an issue when connecting to sqlline.py using the
> CurrentSCN=1490918400000
> (3/31/2017)
>
> I get >> java.sql.SQLException: ERROR 1010 (42M01): Not allowed to mutate
> table.
>
> I use TS=1 day prior to last timestamp in row data (
> timestamp=1491004800000 (4/1/2017)) and my data has only a single day's
> worth of data.
>
> However, interestingly I got no error at all when just connecting without
> this parameter.
>
> Running 'describe' on my table in Hbase I get the following:
>
> Table MyTable is ENABLED
> MyTable, {TABLE_ATTRIBUTES => {coprocessor$1 => '|org.apache.phoenix.
> coprocessor.ScanRegionObserver|805306366|', copr
> ocessor$2 => '|org.apache.phoenix.coprocessor.
> UngroupedAggregateRegionObserver|805306366|', coprocessor$3 =>
> '|org.apache.phoenix.copro
> cessor.GroupedAggregateRegionObserver|805306366|', coprocessor$4 =>
> '|org.apache.phoenix.coprocessor.ServerCachingEndpointImpl|80530636
> 6|', coprocessor$5 => '|org.apache.phoenix.hbase.
> index.Indexer|805306366|org.apache.hadoop.hbase.index.
> codec.class=org.apache.phoenix.i
> ndex.PhoenixIndexCodec,index.builder=org.apache.phoenix.
> index.PhoenixIndexBuilder'}
> COLUMN FAMILIES DESCRIPTION
> {NAME => 'M', BLOOMFILTER => 'ROW', VERSIONS => '1', IN_MEMORY => 'false',
> KEEP_DELETED_CELLS => 'FALSE', DATA_BLOCK_ENCODING => 'FAST_
> DIFF', TTL => 'FOREVER', COMPRESSION => 'SNAPPY', MIN_VERSIONS => '0',
> BLOCKCACHE => 'true', BLOCKSIZE => '65536', REPLICATION_SCOPE =>
> '0'}
>
> Is it OK if I CREATE the table without this CurrentSCN parameter?
>
> The data appears to be there and I can query it, so it seems like it's
> working.
>
> Thanks,
> Michael
>
> On Thu, Jun 8, 2017 at 5:04 PM, Ankit Singhal <ankitsingha...@gmail.com>
> wrote:
>
>> Hi Michael,
>>
>> bq. "exact DDL" Does this mean including all qualifiers like
>> COMPRESSION='SNAPPY', SALT_BUCKETS=64, ... etc...? If we don't use the
>> exact DDL, will Phoenix not behave correctly?
>> yes, Phoenix will not behave well if properties affecting the write path
>> are not consistent during the read time, SALT_BUCKETS=64 is an important
>> one.
>>
>> bq.if we want to add or remove IMMUTABLE_ROWS=true from the CREATE
>> statement?
>> Yes, you can ignore IMMUTABLE_ROWS=true or alter table to mutable later.
>>
>> {code}
>> ALTER TABLE table SET IMMUTABLE_ROWS=false
>> {code}
>>
>> bq. Also, is it correct to assume that the "1 day less" timestamp is
>> just so we use a timestamp prior to the CurrentSCN?
>> Using CurrentSCN less than the oldest timestamp of data during DDL will
>> just avoid adding empty KV for each row. As you are renaming the
>> existing Phoenix table, these empty KV will already be there and you will
>> just save time by doing so.
>>
>> Regards,
>> Ankit Singhal
>>
>> On Thu, Jun 8, 2017 at 1:34 PM, Michael Young <yomaiq...@gmail.com>
>> wrote:
>>
>>> I have a doubt about step 2 from Ankit Singhal's response in
>>> http://apache-phoenix-user-list.1124778.n5.nabble.com/Phoeni
>>> x-4-4-Rename-table-Supported-td1781.html
>>>
>>> He says:
>>>
>>> 2. Open phoenix connection at timestamp 1 day less than the oldest data
>>> in your tables ( by specifying ts in CurrentSCN ./sqlline.py
>>> "localhost;CurrentSCN=<ts>") and create table with the exact DDL used
>>> for old table but with the table name changed to new table
>>>
>>> "exact DDL" Does this mean including all qualifiers like
>>> COMPRESSION='SNAPPY', SALT_BUCKETS=64, ... etc...?
>>>
>>> If we don't use the exact DDL, will Phoenix not behave correctly? Is it
>>> possible to add or change from that list, for example if we want to add or
>>> remove IMMUTABLE_ROWS=true from the CREATE statement?
>>>
>>> Also, is it correct to assume that the "1 day less" timestamp is just so
>>> we use a timestamp prior to the CurrentSCN?
>>>
>>>
>>> On Wed, Jun 7, 2017 at 5:06 PM, Michael Young <yomaiq...@gmail.com>
>>> wrote:
>>>
>>>> ah ha....after some googling I found some info from Ankit, copied below
>>>>
>>>> Looks like I was missing step 2. I don't know how to get the CurrentSCN.
>>>>
>>>> Can someone help me with this?
>>>>
>>>> ====== From
>>>> http://apache-phoenix-user-list.1124778.n5.nabble.com/Phoenix-4-4-Rename-table-Supported-td1781.html
>>>> ====
>>>>
>>>> Currently there is no sql construct but you can do it by following
>>>> below steps.(It is highly recommended you try these steps in dev
>>>> environment before proceeding to production.
>>>>
>>>> 1. Take snapshot of the original table from hbase shell and restore it
>>>> with another table name.
>>>>
>>>> hbase> disable 'oldtablename'
>>>>
>>>> hbase> snapshot 'oldtablename', 'oldtablename_Snapshot'
>>>>
>>>> hbase> clone_snapshot 'oldtablename_Snapshot', 'newTableName'
>>>>
>>>> 2. Open phoenix connection at timestamp 1 day less than the oldest data
>>>> in your tables ( by specifying ts in CurrentSCN ./sqlline.py
>>>> "localhost;CurrentSCN=<ts>") and create table with the exact DDL used
>>>> for old table but with the table name changed to new table.
>>>>
>>>> 3. confirm that your new table is working fine as expected .
>>>> 4. Then drop the old table from phoenix and snapshot from hbase shell.
>>>>
>>>> hbase> delete_snapshot 'oldtablename_Snapshot'
>>>>
>>>>
>>>>
>>>> On Wed, Jun 7, 2017 at 4:58 PM, Michael Young <yomaiq...@gmail.com>
>>>> wrote:
>>>>
>>>>> It is possible to rename a table in Hbase, but it doesn't appear to be
>>>>> recognized by Phoenix.
>>>>>
>>>>> I use the approach documented for HBase:
>>>>>
>>>>> disable 'MySchema.TABLE1'
>>>>> snapshot 'MySchema.TABLE1', 'MySchema.TABLE1_SNAPSHOT'
>>>>> clone_snapshot 'MySchema.TABLE1_SNAPSHOT', NewSchema.TABLE1'
>>>>> delete_snapshot 'MySchema.TABLE1_SNAPSHOT'
>>>>> #drop 'MySchema.TABLE1' - let's test before dropping
>>>>>
>>>>> However, when testing this Phoenix doesn't seem to see the new cloned
>>>>> table and there is nothing in the SYSTEM.CATALOG for it, even after
>>>>> restarting the phoenix client.
>>>>>
>>>>> Should this mechanism work in Phoenix or is there another way to
>>>>> rename or clone an existing table?
>>>>>
>>>>> Michael
>>>>>
>>>>>
>>>>
>>>
>>
>
