Alex Behm has posted comments on this change.

Change subject: IMPALA-3719: Simplify CREATE TABLE statements with Kudu tables

Patch Set 7:

File fe/src/test/java/org/apache/impala/analysis/

Line 1350:     // CTAS in an external Kudu table
What's the rationale for not allowing this?

Line 1716:     AnalyzesOk("create table tab (x int, y string, primary key(x, 
y)) " +
Can you add a brief comment explaining the table layout for this one?

Line 1717:         "distribute by hash(x) into 3 buckets, range(y) split rows " 
can we distribute by range, hash?

Line 1723:     AnalyzesOk("create table tab (a int, b int, c int, d int, 
primary key (a, b, c))" +
What happens if I specify PARTITION BY for a Kudu table?

Line 1739:     AnalysisError(String.format("create table tab (x int) distribute 
by hash (x) " +
What about specifying the other params in tblproperties like the distribute by 
and split rows.

Line 1748:     AnalysisError("create table tab (x int primary key, primary 
key(x)) stored " +
Add negative test where two ColumnDefs are declared as PK.

Line 1762:     AnalysisError("create table tab (a int, b int, c int, d int, 
primary key(a, b, c)) " +
Do we have tests somewhere for checking which types are supported with Kudu? We 
should make sure that:
* you can create a table with all supported types (and same for the specific 
clauses like primary key, distributed by, etc.)
* you cannot create tables with unsupported types like TIMESTAMP/DECIMAL and 
nested types (should fail gracefully with "not supported")
* or alternatively, if we want to defer the type checks to Kudu (and not bake 
it into Impala analysis), then we should document that somewhere

Line 1772:     // No float split keys
Even if the column type is float? If so, might want to test that.

Line 1810:     // DISTRIBUTE BY is required for managed tables.
Primary key is also required, do we have a test?

Line 1812:         "Table partitioning must be specified for managed Kudu 
Let's rephrase this as "Table distribution must be specified ..."

PS6, Line 1828: AnalysisError("create external table t tblproperties (" +
Not that it makes any sense, but hat happens with:

create external table t (primary key()) ...

Line 1863:   public void TestCreateAvroTest() {
Add a test with some of the Kudu-specific clauses and STORED AS AVRO

Line 2822:   public void TestShowFiles() throws AnalysisException {
DO we have a TODO/JIRA somewhere to go through all DDL/SHOW commands and make 
them behave properly for Kudu?
File fe/src/test/java/org/apache/impala/analysis/

Line 1632
Why remove this? It will break my setup :)

Line 2235:     ParsesOk("CREATE TABLE foo (i INT PRIMARY KEY, PRIMARY KEY(i)) 
Add case like this:

Line 2541:     ParsesOk("CREATE TABLE Foo TBLPROPERTIES ('a'='b', 'c'='d') AS 
SELECT * from bar");
nit: let's be consistent with how we chop up string literals across lines 
(space at end of previous line xor beginning of next line)
File fe/src/test/java/org/apache/impala/catalog/

Line 58:         "org.apache.impala.hive.serde.ParquetInputFormat",
File testdata/bin/

Line 203:   if row_format and file_format == 'text':
I think row_format is also valid for sequence files (maybe we're not using it 
File testdata/datasets/functional/functional_schema_template.sql:

Line 823: distribute by range(id) split rows ((1003), (1007)) stored as kudu;
ah so much better

Line 218: create table kudu_table_clone like functional_kudu.alltypes
Why can't we check this in analysis?
File testdata/workloads/functional-query/queries/QueryTest/kudu_create.test:

Line 3: # This test file contains several cases for what basically amount to 
analysis errors,
Should mention that some of this behavior is intentional and why.

Line 11: ImpalaRuntimeException: Type TIMESTAMP is not supported in Kudu
Do we get the same message for DECIMAL and complex types? (No need to add 
another test, just asking whether you've checked).

Line 14: create table t primary key (id) distribute by hash (id) into 3 buckets
Add test for creating and querying a table that has Impala keywords as the 
table name and some column names.
File tests/common/

Line 69:   def get_db_name(cls):
Why not use the unique_database fixture? Sure, we don't run in parallel but 
unique_database seems saner (no need to explain all these framework intricacies)

Line 94:        name will be used. If 'prepend_db_name' is True, the table name 
will be prepended
what does the db_name parameter do then?
File tests/query_test/

Line 57:   def test_insert_update_delete(self, vector, unique_database):
Can we keep the .test file name and the python test function consistent? i.e. 
rename with to test_kudu_crud
File tests/query_test/

Line 192:        'show_create_sql' can be templates that can be used with 
str.format(). format()
In our other SHOW CREATE TABLE tests we also try to run execute the output of 

Line 213:         TBLPROPERTIES 
Why include these TBLPROPERTIES?

is the SPLIT ROWS (...) legal syntax?

To view, visit
To unsubscribe, visit

Gerrit-MessageType: comment
Gerrit-Change-Id: I7b9d51b2720ab57649abdb7d5c710ea04ff50dc1
Gerrit-PatchSet: 7
Gerrit-Project: Impala-ASF
Gerrit-Branch: master
Gerrit-Owner: Dimitris Tsirogiannis <>
Gerrit-Reviewer: Alex Behm <>
Gerrit-Reviewer: Dimitris Tsirogiannis <>
Gerrit-Reviewer: Marcel Kornacker <>
Gerrit-Reviewer: Matthew Jacobs <>
Gerrit-Reviewer: Michael Brown <>
Gerrit-HasComments: Yes

Reply via email to