[
https://issues.apache.org/jira/browse/HIVE-18238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16310285#comment-16310285
]
Zoltan Haindrich commented on HIVE-18238:
-----------------------------------------
[~ekoifman] ...in the latest patch I'm doing a very similar thing - by creating
a new conf in {{QueryState}} ; but the broken test number have raised again so
I might probably step back to only prevent hiveconf changes for intra project
parts (service/cli/etc) - just like in the earlier patches.
In the near future I would like to add some re-execution logic which in this
way haven't has to tweak everything in the driver - instead; I will try to
clean some parts of it.
I will keep in mind that earlier Driver had a separate config; but
unfortunately currently there are some pieces which can't live without modify
session level configs...
I've collected the configs which have been "restored" to do session level
changes in the latest patch:
| {{hive.query.string}} | the user can take a look at the last query...I
haven't seen any other uses so far.. thank you [~stakiar] for the info; it's
very intresting, IIRC there is some rest api which give much more detailed
information about the executed queries... I feel that using that service would
be better for the user |
| {{hive.query.id}} | the druid storage driver uses {{Session.get().getConf()}}
to acquire the current query id; to calculate a scratch-dir name - in case of
parallel execution this might be cause severe problems - I've tried to send the
correct conf; but I ended up changing too many things... I think that the
Storage driver is more closer to be a session level thing; than to be a query
level construct; so I feel that probably the Druid storage handler should be
modified to use a random id to get a scratch dir... |
| {{hive.doing.acid}} | I think this is some leftover flag...I feel that once
set; it's never been unset; and it also needs session level - I think this can
be removed |
> Driver execution may not have configuration changing sideeffects
> -----------------------------------------------------------------
>
> Key: HIVE-18238
> URL: https://issues.apache.org/jira/browse/HIVE-18238
> Project: Hive
> Issue Type: Sub-task
> Components: Logical Optimizer
> Reporter: Zoltan Haindrich
> Assignee: Zoltan Haindrich
> Attachments: HIVE-18238.01wip01.patch, HIVE-18238.02.patch,
> HIVE-18238.03.patch
>
>
> {{Driver}} executes sql statements which use "hiveconf" settings;
> but the {{Driver}} itself may *not* change the configuration...
> I've found an example; which shows how hazardous this is...
> {code}
> set hive.mapred.mode=strict;
> select "${hiveconf:hive.mapred.mode}";
> create table t (a int);
> analyze table t compute statistics;
> select "${hiveconf:hive.mapred.mode}";
> {code}
> currently; the last select returns {{nonstrict}} because of
> [this|https://github.com/apache/hive/blob/7ddd915bf82a68c8ab73b0c4ca409f1a6d43d227/ql/src/java/org/apache/hadoop/hive/ql/parse/SemanticAnalyzer.java#L1696]
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
