hive-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter Vary (JIRA)" <>
Subject [jira] [Commented] (HIVE-14374) BeeLine argument, and configuration handling cleanup
Date Thu, 04 Aug 2016 09:16:20 GMT


Peter Vary commented on HIVE-14374:

Looked up from the code and jira the remaining attributes:
- entirelineascommand - required for SchemaTool, but not intended for public usage
- maxheight, maxwidth - was not able to find about the intended usage (do we need a command
line argument for it, or not) - maxwidth specifically not saved, but loaded, and possible
to set by a commandline argument. Maybe [~cwsteinbach], or [~ashutoshc] could tell more. Otherwise
I think it would be a good idea to set it from command line.
- timeout - the code does not uses it, jira does not help. Maybe [~cwsteinbach], or [~ashutoshc]
could tell more. Otherwise I think it would should remove it altogether.
- showelapsedtime - the jira does not help, but I think it would be a good idea to set it
from command line.
- lastconnectedurl - looking through the jira (HIVE-13670), the author ([~sushanth]) was avare
of the "using reflection to set command line arguments" feature, but still not put into the
documentation. So I think this is not intended as a command line argument. [~sushanth] please
comment, if I missunderstand anything. Otherwise we should remove the command line setting
- trimscripts - the jira does not help, but I think it would be a good idea to set it from
command line.
- historyfile - the jira does not help, but I think it would be a good idea to set it from
command line.

> BeeLine argument, and configuration handling cleanup
> ----------------------------------------------------
>                 Key: HIVE-14374
>                 URL:
>             Project: Hive
>          Issue Type: Improvement
>          Components: Beeline
>    Affects Versions: 2.2.0
>            Reporter: Peter Vary
>            Assignee: Peter Vary
> BeeLine uses reflection, to set the BeeLineOpts attributes when parsing command line
arguments, and when loading the configuration file.
> This means, that creating a setXXX, getXXX method in BeeLineOpts is a potential risk
of exposing an attribute for the user unintentionally. There is a possibility to exclude an
attribute from saving the value in the configuration file with the Ignore annotation. This
does not restrict the loading or command line setting of these parameters which means there
are many undocumented "features" as-is, like setting the lastConnectedUrl, allowMultilineCommand,
maxHeight, trimScripts, etc. from command line.
> This part of the code needs a little cleanup.
> I think we should make this exposure more explicit, and be able to differentiate the
configurable options depending on the source (command line, and configuration file), so I
propose to create a mechanism to tell explicitly which BeeLineOpts attributes are settable
by command line, and configuration file, and every other attribute should be inaccessible
by the user of the beeline cli.
> One possible solution could be two annotations like these:
> - CommandLineOption - there could be a mandatory text parameter here, so the developer
had to provide the help text for it which could be displayed to the user
> - ConfigurationFileOption - no text is required here
> Something like this:
> - This attribute could be provided by command line, and from a configuration file too:
> {noformat}
> @CommandLineOption("automatically save preferences")
> @ConfigurationFileOption
> public void setAutosave(boolean autosave) {
>   this.autosave = autosave;
> }
> public void getAutosave() {
>   return this.autosave;
> }
> {noformat}
> - This attribute could be set through the configuration only
> {noformat}
> @ConfigurationFileOption
> public void setLastConnectedUrl(String lastConnectedUrl) {
>   this.lastConnectedUrl = lastConnectedUrl;

> }

> public String getLastConnectedUrl()
> {

>   return lastConnectedUrl;
> - Attribute could be set through command line only - I think this is not too relevant,
but possible
> {noformat}
> @CommandLineOption("specific command line option")
> public void setSpecificCommandLineOption(String specificCommandLineOption) {
  this.specificCommandLineOption = specificCommandLineOption;

> public String getSpecificCommandLineOption() {
  return specificCommandLineOption;
> - Attribute could not be set
> {noformat}
> public static Env getEnv() {
  return env;

public static void setEnv(Env envToUse) {
  env = envToUse;
> {noformat}
> Accouring to our previous conversations, I think you might be interested in: 
> [~spena], [~vihangk1], [~aihuaxu], [~ngangam], [~ychena], [~xuefuz]
> but anyone is welcome to discuss this.
> What do you think about the proposed solution?
> Any better ideas, or extensions?
> Thanks,
> Peter

This message was sent by Atlassian JIRA

View raw message