hive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan Gates <alanfga...@gmail.com>
Subject Re: [DISCUSS] Deprecating Hive CLI
Date Fri, 24 Apr 2015 22:38:59 GMT
If I understand correctly this is an argument about usability, not 
functionality.  So if Hive still had the CLI but it happened to use 
either HS2 or embedded HS2 (depending on configuration) underneath your 
concerns would be addressed.  Is that correct?

Alan.

> Lars Francke <mailto:lars.francke@gmail.com>
> April 23, 2015 at 15:53
> I've been at about 20 different customers in the years since Beeline 
> has been added. I can only think of a single one that has used 
> beeline. The instinct is to use "hive", partially because it is easy 
> to remember and intuitive and because it is easier to use. I end up 
> googling the stupid JDBC syntax every single time.
>
> I know this might be a bit "out there" but I propose something else:
> 1) Rename (or link) "beeline" to "hive"
> 2) Add a "--hiveserver2" (or "--jdbc" or "--beeline") option to the 
> "hive" command to get the current "beeline", this'd keep the CLI as 
> default, we could also add a "--legacy" or "--cli" option and make 
> "hiveserver2/beeline" the default.
> 3) Add a "--embedded-hs2" option to the "hive" command to get an 
> embedded HS2 in Beeline
> 4) Add some documentation to beeline reminding people on startup of 
> beeline on how to connect and how to use embedded mode
>
> The fact is that the old shell just works for lots of people and 
> there's just no need for beeline for these people. Also the name is 
> confusing - especially for non-native speakers. It's not a common word 
> so it's not easy to remember.
>
>
> Alan Gates <mailto:alanfgates@gmail.com>
> April 23, 2015 at 15:35
> Xuefu, thanks for getting this discussion started.  Limiting our code 
> paths is definitely a plus.  My inclination would be to go towards 
> option 2.  A few questions:
>
> 1) Is there any functionality in CLI that's not in beeline?
> 2) If I understand correctly option 2 would have an implicit HS2 in 
> process when a user runs the CLI.  Would this be available in option 1 
> as well?
> 3) Are there any performance implications, since now commands have to 
> hop through a thrift/jdbc loop even in the embedded mode?
> 4) If we choose option 2 how backward compatible can we make it?  Will 
> users need to change any scripts they have that use the CLI?  Do we 
> have tests that will make sure of this?
>
> Alan.
>
> Xuefu Zhang <mailto:xzhang@cloudera.com>
> April 23, 2015 at 14:43
> Hi all,
>
> I'd like to revive the discussion about the fate of Hive CLI, as this 
> topic
> has haunted us several times including [1][2]. It looks to me that 
> there is
> a consensus that it's not wise for Hive community to keep both Hive CLI as
> it is as well as Beeline + HS2. However, I don't believe that no action is
> the best action for us. From discussion so far, I see the following
> proposals:
>
> 1. Deprecating Hive CLI and advise that users use Beeline.
> 2. Make Hive CLI as naming flavor to beeline with embedded mode.
>
> Frankly, I don't see much difference between the two approaches. 
> Keeping an
> alias at script or even code level isn't that much work. However, 
> shouldn't
> we pick a direction and start moving to it? If there is any gaps between
> beeline embedded and Hive CLI, we should identify and fill in those.
>
> I'd love to hear the thoughts from the community and hope this time we 
> will
> have concrete action items to work on.
>
> Thanks,
> Xuefu
>
> [1]
> http://mail-archives.apache.org/mod_mbox/hive-dev/201412.mbox/%3C5485E1BE.3060709%40hortonworks.com%3E
> [2] https://www.mail-archive.com/dev@hive.apache.org/msg112378.html
>

Mime
View raw message