[ https://issues.apache.org/jira/browse/HIVE-1096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12835785#action_12835785 ]
Edward Capriolo commented on HIVE-1096: --------------------------------------- {quote} True, but I think we should try to improve the situation. As a start we can add code to throw an error if hive-default.xml or hive-site.xml sets a hive.* configuration property that is not defined in HiveConf. This would protect the hive.* namespace and at the same time make it easy to track down cases where folks misspell a hive.* property name. {quote} I only see one problem with this. HiveConf has an enumeration of valid properties. I do not think Hadoop Conf shares that trait. So if someone were to say: {noformat} set hadoop.wrong.variable.name {noformat} Would we have a simple way of knowing if that variable was variable is valid. Anyway that is out of scope a bit. {quote} ${namespace:variable_name}. {quote} I like this. How about? {noformat} ${hiveconf:variable_name}. ${env:variable_name}. ${property:variable_name}. {noformat} This way we do not need the "-hivevar x=y" switch." I say this because we already have three mechanism to pass data into Java/hive adding a forth is a little confusing. The only problem with introducing this is now we have a new question. How do we extend SET to read/write these? > 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 > Attachments: 1096-9.diff, hive-1096-2.diff, hive-1096-7.diff, > hive-1096-8.diff, hive-1096.diff > > > 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.