Add suport for passing multiple statements to setConnectionInitSql() call

[yakuninv]

Hello people,

In our application we are useing worse performing pool and our plan is to change it to use HikariCP pool to connect Hive via Jdbc. During assesment we found out that HikariCP doesn't support multiple statements in init sql. And it is serious blocker for us as hive connection needs to be properly setup via properties set in init sql like in example below.

  Set<String> sqls = new LinkedHashSet<>();
  sqls.addAll(CollectionUtils.listOf(
  "use " + dbSchema, // Set schema
  "set hive.exec.dynamic.partition.mode=nonstrict", // Allows dynamic partitioning
  "set hive.query.result.fileformat=SequenceFile" // File format for intermediate results
  ));
  dataSource.setConnectionInitSqls(sqls)

So my question would it be possible to extend HikariConfig.setConnectionInitSql() to support multiple statements? Or it is somehow against some design principles?

With regards, Sla

[brettwooldridge]

Can you separate those commands with semi-colons?

[yakuninv]

Hi @brettwooldridge,

I tried and this doesn't work (. And the same is said in articles below.

https://community.cloudera.com/t5/Support-Questions/Hive-JDBC-drivers-support-to-execute-multiple-SQL-Statements/td-p/79630 https://stackoverflow.com/questions/37678990/execute-multiple-hive-queries-using-single-execute-method-of-statement-class-u

Thanks Sla

[aboutZZ]

Any updates? Is the team have plan to supprot multiple statements?

[tomdcc]

I have a similar request - we'd like to capture db warnings and / or errors emitted during the connection init and log the warnings / optionally ignore certain errors.

I think a more flexible approach that wouldn't balloon into supporting many different types of init would be to allow setting something like a Consumer<Connection> (that can throw a SQLException though) instead of the sql string - when that happens, the passed-in code is responsible for initializing the connection however it wants to and this would basically be called instead of running the sql string through executeSql(). The simple string form would remain for most users; anyone else can pass in a handler to to whatever they want more flexibly.

@brettwooldridge If this is a direction you'd like to go I can submit a PR.