[ 
https://issues.apache.org/jira/browse/HIVE-20608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16665241#comment-16665241
 ] 

Soumabrata Chakraborty edited comment on HIVE-20608 at 10/26/18 2:22 PM:
-------------------------------------------------------------------------

Hi [~daijy]

Yes - the code you pointed out from ExecuteStatementOperation.java does trim 
the statement and at this moment is the only point from which 
HiveCommandOperation's runInternal() method may be reached.

However,  I believe HiveCommandOperation.java and runInternal() should be self 
sufficient and should not depend on operation in another class to trim the 
statement for it.

In fact, if you look at the current code for HiveCommandOperation.java then it 
does trim the statement on line 109 (self sufficiency) but fails to use this 
trimmed version in next line (i.e. line 110).  This is exactly what my change 
fixes. 

References: 
 # 
[https://github.com/apache/hive/blob/0d7015468611c485c01bb80cdbe4c89e4e68b680/service/src/java/org/apache/hive/service/cli/operation/HiveCommandOperation.java#L109]
 # 
[https://github.com/apache/hive/pull/442/files#diff-459cb15e0bcb0c7f00727e0dcf63a3b0]
 

I agree that functionally it is not a bug at the moment.  That said, I think 
this change shall make the code more robust.

I leave it up to your discretion to decide on the course of action.


was (Author: soumabrata):
Hi [~daijy]

Yes - the code you pointed out from ExecuteStatementOperation.java does trim 
the statement and at this moment is the only point from which 
HiveCommandOperation's runInternal() method may be reached.

However,  I believe HiveCommandOperation.java and runInternal() should be self 
sufficient and should not depend on operation in another class to trim the 
statement for it.

In fact, if you look at the current code for HiveCommandOperation.java then it 
does trim the statement on line 109 (self sufficiency) but fails to use this 
trimmed version in next line (i.e. line 110).  This is exactly what my change 
fixes.  (Reference 
https://github.com/apache/hive/blob/0d7015468611c485c01bb80cdbe4c89e4e68b680/service/src/java/org/apache/hive/service/cli/operation/HiveCommandOperation.java#L109)

I agree that functionally it is not a bug at the moment.  That said, I think 
this change shall make the code more robust.

I leave it up to your discretion to decide on the course of action.

> Incorrect handling of sql command args in hive service leading to misleading 
> error messages
> -------------------------------------------------------------------------------------------
>
>                 Key: HIVE-20608
>                 URL: https://issues.apache.org/jira/browse/HIVE-20608
>             Project: Hive
>          Issue Type: Bug
>            Reporter: Soumabrata Chakraborty
>            Assignee: Soumabrata Chakraborty
>            Priority: Major
>         Attachments: HIVE-20608.2.patch, HIVE-20608.patch
>
>
> *Steps to reproduce:*
> (1) Connect to HiveServer2 using JDBC driver (not via Beeline)
> (2) Execute a set command with a space before set – e.g. " set 
> hive.exec.dynamic.partiton=true"
> (3) The error that is returned says: 
> {code:java}
> Caused by: org.apache.hive.service.cli.HiveSQLException: Error while 
> processing statement: Cannot modify set hive.exec.dynamic.partition at 
> runtime. It is not in list of params that are allowed to be modified at 
> runtime
> {code}
>  (4) However on removing the space before the set command - it works fine.
>  
> *Analysis:*
> Looks like an issue with 
> [https://github.com/apache/hive/blob/master/service/src/java/org/apache/hive/service/cli/operation/HiveCommandOperation.java]
>  
> In the runInternal() method, the untrimmed sql statement is split by space 
> (\\s) but the substring operation to get the command args is done on the 
> trimmed sql statement.  This causes the issue. 
> {code:java}
> String command = getStatement().trim(); 
> String[] tokens = statement.split("\\s"); 
> String commandArgs = command.substring(tokens[0].length()).trim();
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to