hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Hsieh <...@cloudera.com>
Subject Re: HBase shell compatibility needs
Date Thu, 14 Aug 2014 20:16:22 GMT
I've always found working with the jruby part of the hbase shell jarring
because many of the hbase commands don't interact "natively" with jruby
constructs.  Some work was done [1] [2] to make it a little better but it
is in that uncanny half-there half-not-there state.

More inline

[1] https://issues.apache.org/jira/browse/HBASE-5548
[2] https://issues.apache.org/jira/browse/HBASE-7353

On Thu, Aug 14, 2014 at 11:53 AM, Sean Busbey <busbey@cloudera.com> wrote:

> Hiya Folks!
> Right now, the HBase shell relies on an old version of JRuby (1.6, last
> released ~2 years ago) and a very old version of Ruby (1.8).
> I'd like to start working towards refactoring the shell. Updating some of
> our underlying libraries will make it easier to fix up some of our low
> hanging improvements (start up latency, utf8 support).
> This got me wondering about what the bounds of changing are (esp for
> master).
> 1) How common is making use of the fact that our shell is actually and IRB
> session? Do we want to keep encouraging that for users? Could we change the
> focus of the IRB version to be developers of HBase? Could we just make a
> HBase client gem and provide instructions for using it in IRB?
Most admin work and much "repair" work happens in the shell.

If a gem makes it super easy for folks to get started with hbase that
sounds good.  It does seem we'd need to haev a gem for each major version's
shelll to maintain compatibility if the gem is hosted separately from the
hbase release though, no?

> 2) However extensive our keeping IRB is, do we need to keep the same Ruby
> compatibility? Spanning Ruby 1.8 and 1.9 is a pain, but possible. (I know
> very few people still using 1.8 though) When Ruby 2 support lands
> supporting either of those won't be possible, because at that point JRuby
> will only support Ruby 2.1[1].

I have a slight preference for keeping modern.

> 3) Do we have any guidance on compatibility across versions for the shell?
> I couldn't find anything obvious.

I believe the shell is one of those intefaces that has stayed relatively
stable through the years -- primarily due to relative neglect.

> 4) Lacking #2, what do we want to ensure keeps working the same? Existing
> shell commands in the exact form they have now? Table variables (as opposed
> to setting a "current table" context for the shell session)?
> I have a preference for a more ruby-esque and more oo style of api for the
shell.  Today it is a frankenshell that is partially oo ruby style, and
partially procedural sql-shell-style.  I'd even consider a new "user shell"
that is parallel to the current "hacker" shell, with the goal marginalizing
the current shell for low level repair work.

> [1]: https://groups.google.com/d/msg/jruby-users/qmLpZ7qDwZo/J_iYViplcq4J
> --
> Sean

// Jonathan Hsieh (shay)
// HBase Tech Lead, Software Engineer, Cloudera
// jon@cloudera.com // @jmhsieh

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message