If ; appears in string literals in a query the hive cli is not able to escape them properly.
A UDF that can export data to JDBC databases.
I actually am working on a UDF where this became an issue. My .q file looks like this.
,'CREATE TABLE app_info ( kkey VARCHAR(255) NOT NULL, vvalue VARCHAR(255) NOT NULL )') , dboutput('jdbc:derby:../build/test_dboutput_db','','',
'INSERT INTO app_info (kkey,vvalue) VALUES (?,?)','1','a')
the ';create=true' section is failing. My nickname is 'Corner Case'
Updated CLIDriver and added test case
This patch allows an escaped ; in a string. Removes the escape before passing the query to the driver.
It seems cleaner to modify hive.g instead of adding more parsing/manipulation of query strings in CliDriver.
That is a good point. However it seems that the CLIDriver will be have to change regardless. Since the CLIDriver is specifically splitting on ';' a statement like "set a=5; set b=8" gets passed as two separate qp.run()'s.
Digging into this some more it seems that the query processor and cli driver would have to work together in a different way.
As of now the CLIDriver is physically splitting on ';' it can not tell the difference between ';' and '/;'. My patch adds some logic to detect '/;' and unescape it before passing to qp.run(String).
Right now we can argue that the CliDriver has an implicit 'autocommit=true'. We can make this an explicit variable. with autocommit='false' the query processor would hold a StringBuffer or a queue of query strings. 'commit ' ; would cause QP to run each query in its queue.
This is a non-trivial change. If we add this feature we can set autocommit=true so the default behavior does not change. For no though my patch has a fairly way to deal with this problem.
Ownership = Patch submitter...
The changes look OK to me -
Raghu, for this to work with Hive.g - the entire string would have to be passed to qp. So, essentially qp will take in a bunch of queries and then parse them instead of getting one query at a time.
This requires substantial change and should not block https://issues.apache.org/jira/browse/HIVE-645
@Raghu, are you OK with this change - it is OK from my end
Committed. Thanks Edward