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 <bus...@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 // j...@cloudera.com // @jmhsieh
