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
