[
https://issues.apache.org/jira/browse/HIVE-14374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15401903#comment-15401903
]
Peter Vary commented on HIVE-14374:
-----------------------------------
{panel:title=Missing wiki documentation, but existing help documentation}
-a (authType) - jdbc connection authentication type
-i <init file> script file for initialization
--property-file=<property-file> the file to read connection properties (url,
driver, user, password) from
--addlocaldriverjar=DRIVERJARNAME Add driver jar file in the beeline client side
--addlocaldrivername=DRIVERNAME Add drivier name needs to be supported in the
beeline client side
--incremental=[true/false] When set to false, the entire result set is fetched
and buffered before being displayed...
--showConnectedUrl=[true/false] Prompt HiveServer2's URI to which this beeline
connected.
{panel}
Handling the ones abover is easy. Just add the documentation to wiki, I will do
this
{panel:title=Configuration file specific, and could be set by command line as
well}
entirelineascommand - should beeline try to split the commands on ;
maxheight - set by the terminal on start, but could be overwritten by command
line
maxwidth - set by the terminal on start, but could be overwritten by command
line
timeout - did not set/get - do not know what is it about
showelapsedtime - on commit, rollback, execute should beeline print the elapsed
time
lastconnectedurl - used by -r (reconnect) to connect to the database, but could
be overwritten by command line
trimscripts - should beeline trim the script lines before executing
historyfile - where should be the history file saved (absolute path)
{panel}
Handling these is more complicated. [~leftylev] I have seen, that you know
about the documentation of the parameters. Do you know anything about these
features? Are these are planned and just the documentation is lacking, or the
possiblity of setting these parameters is an unintended "feature"? Or I just
have to dig the code, and try to guess from there?
The question is still stands, only we have more data now:
- Do we create 2 groups of parameters for command line parameters, and
configuration file parameters, or we use only one group?
I think we might have only one group, and it would be used for both type of
parameters just as [~stakiar] proposed.
> BeeLine argument, and configuration handling cleanup
> ----------------------------------------------------
>
> Key: HIVE-14374
> URL: https://issues.apache.org/jira/browse/HIVE-14374
> 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;
>
}
>
{noformat}
> - 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;
>
}
>
{noformat}
> - 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
(v6.3.4#6332)
