> On March 22, 2018, 4:22 p.m., Vihang Karajgaonkar wrote: > > I am a bit confused here. If the full url can be provided in the config > > file by the user, how is it better than just creating a environment > > variable like BEELINE_URL_<name> and use it instead of adding it in the > > config file? I think the objective of this config file was to automatically > > figure out the connection url based on hive-site.xml and the additional > > beeline-hs2-connection.xml to override/augment the information from > > hive-site.xml > > > > The current code is structured such that all keys start with > > beeline.hs2.connection. and components of the url are parsed automatically > > using the values of those keys. If we want to add full support of named > > urls which can have completely different url components like session vars > > etc, what do you think of adding a new prefix key of the form > > beeline.hs2.connection.<name> and then the existing code will work exactly > > like it does currently but instead will parse the keys starting with > > beeline.hs2.connection.<name>. For example, a named url called "blue" will > > be constructed using all the keys from beeline.hs2.connection.blue. That > > way we reuse existing logic. The beeline will be invoked like beeline -c > > blue. Do you see any problems with this approach? This way the user doesn't > > have to provide all the url components which can be reused from > > hive-site.xml (like the nasty ssl, kerberos settings)
Thanks for your feedback. Discussed a bit offline with Thejas as well. Let me add more details on the use case: Suppose you have 2 different sets of HS2 instances running on the cluster, a beeline shell will only be able to parse one hive-site.xml (set 1 for example). To be able to connect to set 2, it would be nice to have an installer (something like Apache Ambari) managed beeline-site.xml, which can publish the named urls (and also regenerate the named urls if the admin makes any change in the cluster manager), which can be used by the beeline shell. Once the base connection url is figured out, beeline-hs2-connection.xml can then be used to overlay user specific driver configs like it is doing right now. Hope that clarifies the use case. I'll post an updated patch based on your feedback above. - Vaibhav ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/66185/#review199770 ----------------------------------------------------------- On March 20, 2018, 10:54 p.m., Vaibhav Gumashta wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/66185/ > ----------------------------------------------------------- > > (Updated March 20, 2018, 10:54 p.m.) > > > Review request for hive, Thejas Nair and Vihang Karajgaonkar. > > > Bugs: HIVE-18963 > https://issues.apache.org/jira/browse/HIVE-18963 > > > Repository: hive-git > > > Description > ------- > > https://issues.apache.org/jira/browse/HIVE-18963 > > > Diffs > ----- > > beeline/src/java/org/apache/hive/beeline/BeeLine.java 402fadddde > > beeline/src/java/org/apache/hive/beeline/hs2connection/HS2ConnectionFileParser.java > b769e8581f > > beeline/src/java/org/apache/hive/beeline/hs2connection/HS2ConnectionFileUtils.java > f635b40633 > > beeline/src/java/org/apache/hive/beeline/hs2connection/UserHS2ConnectionFileParser.java > 2801ebee09 > beeline/src/main/resources/BeeLine.properties 6fca953836 > > beeline/src/test/org/apache/hive/beeline/hs2connection/TestUserHS2ConnectionFileParser.java > 1d17887417 > beeline/src/test/resources/test-hs2-named-connection-config.xml > PRE-CREATION > > itests/hive-unit/src/test/java/org/apache/hive/beeline/hs2connection/BeelineWithHS2ConnectionFileTestBase.java > 3da31ad8a9 > > > Diff: https://reviews.apache.org/r/66185/diff/1/ > > > Testing > ------- > > > Thanks, > > Vaibhav Gumashta > >
