Mailing-List: contact hbase-dev-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hbase-dev@hadoop.apache.org
Message-ID: <1862968448.1211585036566.JavaMail.jira@brutus>
Date: Fri, 23 May 2008 16:23:56 -0700 (PDT)
From: "stack (JIRA)" <jira@apache.org>
To: hbase-dev@hadoop.apache.org
Subject: [jira] Updated: (HBASE-487) Replace hql w/ a hbase-friendly jirb or
 jython shell
In-Reply-To: <246479956.1204571690457.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/HBASE-487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

stack updated HBASE-487:
------------------------

    Attachment: rb.patch

Patch that adds src/ruby and a first attempt at an HBase.rb module with basic imports and 'import Java' statement.  Changes in build.xml add the src/ruby content to the root of the hbase-X.X.X.jar.  I tried usring -r module_name to the irb invocation but looks like CLASSLOADER issues... our modules can't be found on irb invocation (I'd guess only finds stuff in the jruby jar).

Seems too that we need to figure how to get an irbrc into the mix.  In here we can define the prompt among other things.  Do it in a manner that can be overridden; e.g. in an irb.rc that can be found on irb load so users' .irbrc override ours.

> Replace hql w/ a hbase-friendly jirb or jython shell
> ----------------------------------------------------
>
>                 Key: HBASE-487
>                 URL: https://issues.apache.org/jira/browse/HBASE-487
>             Project: Hadoop HBase
>          Issue Type: Wish
>            Reporter: stack
>            Assignee: stack
>            Priority: Minor
>             Fix For: 0.2.0
>
>         Attachments: groovy-2.patch, groovy.patch, jruby.patch, rb.patch
>
>
> The hbase shell is a useful admin and debugging tool but it has a couple of downsides.  To extend, a fragile parser definition needs tinkering-with and new java classes must be added.  The current test suite for hql is lacking coverage and the current code could do with a rewrite having evolved piecemeal.  Another downside is that the presence of an HQL interpreter gives the mis-impression that hbase is like a SQL database.
> This 'wish' issue suggests that we jettison HQL and instead offer users a jirb or jython command line.  We'd ship with some scripts and jruby/jython classes that we'd source on startup to do things like import base client classes -- so folks wouldn't have to remember all the packages stuff sat in -- and added a pretty-print for scanners and getters outputting text, xhtml or binary.  They would also make it easy to do HQL-things in jruby/python script.
> Advantages: Already-written parser with no need of extension probing deeper into hbase: i.e. better for debugging than HQL could ever be.  Easy extension adding scripts/modules rather than java code.  Less likely hbase could be confused for a SQL db.
> Downsides: Probably more verbose.  Requires ruby or python knowledge ("Everyone knows some sql").  Big? (jruby lib is 24M).
> I was going to write security as downside but HQL suffers this at the moment too -- though it has been possible to sort the updates from the selects in the UI to prevent modification of the db from the UI, something that would be hard to do in a jruby/jython parser.
> What do others think?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.