[
https://issues.apache.org/jira/browse/HIVE-1096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804668#action_12804668
]
Edward Capriolo commented on HIVE-1096:
---------------------------------------
John,
I understand your comment.
I have not looked at any of the view related patches, but I do see how views
and variable replacement could pose a complex set of discussions, as would
introducing variables into the grammer itself.
Based on the user requested feature, metastore level changes is a fairly
drastic and complex way to solve a simple problem. If i were a gambling man, I
would bet that the 'Elastic MapReduce version of Hive' does a simple text based
replacement high upstream or possibly outside of hive entirely.
Thus, I proposed some simple string replacement before the query ever hits the
compiler. In the implementation I am suggesting a VIEW could never have a
variable, because it should be replaced before it ever becomes a view.
I see people using this feature like so:
{noformat}
hive -hiveconf DAY=5 -e "LOAD DATA INFILE '/tmp/${DAY}' into logs
partition=${DAY}"
{noformat}
This is a common problem that many people (including myself) face. Do you think
it is short-side thinking to not consider implementing further down in the
process?
> Hive Variables
> --------------
>
> Key: HIVE-1096
> URL: https://issues.apache.org/jira/browse/HIVE-1096
> Project: Hadoop Hive
> Issue Type: New Feature
> Reporter: Edward Capriolo
> Assignee: Edward Capriolo
>
> From mailing list:
> --Amazon Elastic MapReduce version of Hive seems to have a nice feature
> called "Variables." Basically you can define a variable via command-line
> while invoking hive with -d DT=2009-12-09 and then refer to the variable via
> ${DT} within the hive queries. This could be extremely useful. I can't seem
> to find this feature even on trunk. Is this feature currently anywhere in the
> roadmap?--
> This could be implemented in many places.
> A simple place to put this is
> in Driver.compile or Driver.run we can do string substitutions at that level,
> and further downstream need not be effected.
> There could be some benefits to doing this further downstream, parser,plan.
> but based on the simple needs we may not need to overthink this.
> I will get started on implementing in compile unless someone wants to discuss
> this more.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
