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.fran...@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:alanfga...@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:xzh...@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
