trafodion-codereview mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sureshsubbiah <>
Subject [GitHub] incubator-trafodion pull request #949: [TRAFODION-2475] Create table/index o...
Date Thu, 09 Feb 2017 01:05:01 GMT
Github user sureshsubbiah commented on a diff in the pull request:
    --- Diff: core/sql/src/main/java/org/trafodion/sql/ ---
    @@ -294,15 +296,27 @@ private ChangeFlags setDescriptors(Object[] tableOptions,
                    break ;
                case HBASE_COMPRESSION:
                    if (tableOption.equalsIgnoreCase("GZ"))
    +	       {    // throws IOException
    +		   CompressionTest.testCompression(Algorithm.GZ);
    +	       }
                    else if (tableOption.equalsIgnoreCase("LZ4"))
    +	       {   // throws IOException
    +		   CompressionTest.testCompression(Algorithm.LZ4);
    +	       }
                    else if (tableOption.equalsIgnoreCase("LZO"))
    +	       {   // throws IOException
    +		   CompressionTest.testCompression(Algorithm.LZO);
    +	       }
                    else if (tableOption.equalsIgnoreCase("NONE"))
                    else if (tableOption.equalsIgnoreCase("SNAPPY"))
    +	       {   // throws IOException
    +		   CompressionTest.testCompression(Algorithm.SNAPPY);
    +	       }
    --- End diff --
    Good catch Dave. I was confident that invalid compression options like "SNAPY" would be
caught earlier in the parse/bind stage. Now I see that validation of input arguments is not
thorough. I will add a commit to this PR by tomorrow with that change. Much validation can
be done on the C++ side before we call the create()/alter() Java function. For an allowed
compression setting usable by HBase, the only verification I know is the Java one provided
by HBase itself. Therefore this validation could be done once in Java side and results stored
in C++ side or we can do as this PR does, validate and raise error in Java side when necessary.
The method provided by HBase uses static variables to store results of previous validations,
so we will not be fully validating the same compression algorithm twice in a given session.
    This is how the error message looks like now.
    create table test5 (a int not null primary key, b int) hbase_options (compression = 'SNAPPY')
salt using 2 partitions ;
    *** ERROR[8448] Unable to access Hbase interface. Call to ExpHbaseInterface::create()
returned error HBASE_CREATE_ERROR(701). Cause: org.apache.hadoop.hbase.DoNotRetryIOException:
java.lang.RuntimeException: native snappy library not available: this version of libhadoop
was built without snappy support.
    org.trafodion.sql.HBaseClient.createk( Caused by 
    java.lang.RuntimeException: native snappy library not available: this version of libhadoop
was built without snappy support.

If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at or file a JIRA ticket
with INFRA.

View raw message