3

I am dropping multiple partitions of an Impala table via

ALTER TABLE foobar DROP IF EXISTS PARTITION (pkey='foo' OR pkey='bar');

When using impala-shell I am presented a result telling me how many partitions were actually dropped:

Starting Impala Shell without Kerberos authentication
***********************************************************************************
Welcome to the Impala shell.
(Impala Shell v3.2.0-cdh6.3.2 (1bb9836) built on Fri Nov  8 07:22:06 PST 2019)

The SET command shows the current value of all shell and query options.
***********************************************************************************
Opened TCP connection to impala:21000
Connected to impala:21000
Server version: impalad version 3.2.0-cdh6.3.2 RELEASE (build 1bb9836227301b839a32c6bc230e35439d5984ac)
[impala:21000] default> use my_schema;
Query: use my_schema
[impala:21000] my_schema> ALTER TABLE FOOBAR DROP IF EXISTS PARTITION (pkey='foo' OR pkey='bar');
Query: ALTER TABLE FOOBAR DROP IF EXISTS PARTITION (pkey='foo' OR pkey='bar')
+-------------------------+
| summary                 |
+-------------------------+
| Dropped 1 partition(s). |
+-------------------------+
Fetched 1 row(s) in 0.13s

Now, in our productive code, we are stuck using only JDBC. When executing the same DDL statement via JDBC, for my Statement st I have st.getResultSet() == null and st.getUpdateCount() == -1

Is there a way to retrive the number of dropped partitions via JDBC only?

Michael Schaefers
  • 707
  • 4
  • 17
  • I do not think this is possible directly through jdbc and -1 means its a success. You need to use show partitions to calculate before and after change partition to determine how many partitions changed. You can refer to this - https://stackoverflow.com/questions/2511679/python-number-of-rows-affected-by-cursor-executeselect – Koushik Roy Nov 27 '21 at 05:06
  • From what the Impala Source code looks like to me, the impala server returns this Info as a normal query result, a table with one column called summary and one row. (See CatalogOpExecutor.java). In catalog-server.cc, one sees that this data is sent in thrift as TDdlExecResponse back to the client. My guess would be that impala-jdbc somewhere drops this data in result processing, either due to recognizing its a ddl statement or simply not reading TDdlExecResponse completely. As Cloudera doesn't open source the jdbc driver, its no fun to checkout. – Theo Nov 29 '21 at 09:14

0 Answers0