You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@phoenix.apache.org by "Samarth Jain (JIRA)" <ji...@apache.org> on 2015/02/07 01:52:35 UTC

[jira] [Comment Edited] (PHOENIX-1641) Make the upgrade for SYSTEM.CATALOG and SYSTEM.SEQUENCE work for 4.x to 4.3

    [ https://issues.apache.org/jira/browse/PHOENIX-1641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14310335#comment-14310335 ] 

Samarth Jain edited comment on PHOENIX-1641 at 2/7/15 12:51 AM:
----------------------------------------------------------------

bq. This check in UpgradeUtil doesn't look right, as MetaDataProtocol.MIN_SYSTEM_TABLE_TIMESTAMP is now higher that it was before. 

So the checkAndPut operation in the enclosing if block is checking if the SALT_BUCKETS column is already present. In 4.2.0 the column was added and 4.2.1 we had the fix for the case when the salting wasn't actually happening. So the check oldTable.getTimeStamp() == MetaDataProtocol.MIN_SYSTEM_TABLE_TIMESTAMP-1 is really applicable for that special 4.2.0 to 4.2.1 upgrade.  

{code}
if (!sysTable.checkAndPut(seqTableKey,
                    PhoenixDatabaseMetaData.TABLE_FAMILY_BYTES,
                    PhoenixDatabaseMetaData.SALT_BUCKETS_BYTES, null, saltPut)) {
{code}

bq. I don't think your other change to UpgradeUtil is necessary. 

We want to run the "salt the sequence table code" only when the server side is at 4.1.0 or before. If its on 4.2.0 then the previous comment applies. If it is at 4.2.1 then no upgrade is needed. Also, in ConnectionQueryServicesImpl, we are calling upgrade code for the following condition :

{code}
// if the table is at a timestamp corresponding to before 4.2.1 then run the upgrade script
if (currentServerSideTableTimeStamp <= MetaDataProtocol.MIN_SYSTEM_TABLE_TIMESTAMP - 2) {
    if (UpgradeUtil.upgradeSequenceTable(metaConnection, nSaltBuckets, e.getTable())) {
{code}

bq.  Can you instead have separate static constants for MIN_SYSTEM_TABLE_TIMESTAMP_4_1_0, MIN_SYSTEM_TABLE_TIMESTAMP_4_2_1, etc.

Makes sense, will do.   


was (Author: samarthjain):
bq. This check in UpgradeUtil doesn't look right, as MetaDataProtocol.MIN_SYSTEM_TABLE_TIMESTAMP is now higher that it was before. 

So the checkAndPut operation in the enclosing if block is checking if the SALT_BUCKETS column is already present. In 4.2.0 the column was added and 4.2.1 we had the fix for the case when the salting wasn't actually happening. So the check oldTable.getTimeStamp() == MetaDataProtocol.MIN_SYSTEM_TABLE_TIMESTAMP-1 is really applicable for that special 4.2.0 to 4.2.1 upgrade.  

bq. I don't think your other change to UpgradeUtil is necessary. 

We want to trigger the salt the sequence table code only when the server side is at 4.1.0 or before. If its on 4.2.0 then the previous comment applies. If it is at 4.2.1 then no upgrade is needed. Also, in ConnectionQueryServicesImpl, we are calling upgrade code for the following condition :

{code}
// if the table is at a timestamp corresponding to before 4.2.1 then run the upgrade script
if (currentServerSideTableTimeStamp <= MetaDataProtocol.MIN_SYSTEM_TABLE_TIMESTAMP - 2) {
    if (UpgradeUtil.upgradeSequenceTable(metaConnection, nSaltBuckets, e.getTable())) {
{code}

bq.  Can you instead have separate static constants for MIN_SYSTEM_TABLE_TIMESTAMP_4_1_0, MIN_SYSTEM_TABLE_TIMESTAMP_4_2_1, etc.

Makes sense, will do.   

> Make the upgrade for SYSTEM.CATALOG and SYSTEM.SEQUENCE work for 4.x to 4.3
> ---------------------------------------------------------------------------
>
>                 Key: PHOENIX-1641
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-1641
>             Project: Phoenix
>          Issue Type: Bug
>            Reporter: Samarth Jain
>            Assignee: Samarth Jain
>             Fix For: 5.0.0, 4.3
>
>         Attachments: PHOENIX-1641.patch, PHOENIX-1641_v2.patch
>
>
> The code got removed in the commit: https://github.com/apache/phoenix/commit/58c80a1857659962d695bc8e5fe22b4e401b7f0a
>  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)