hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "edward yoon" <edw...@udanax.org>
Subject Re: [jira] Commented: (HBASE-487) Replace hql w/ a hbase-friendly jirb or jython shell
Date Tue, 11 Mar 2008 02:02:23 GMT
HQL character is quite different from Hbase, like you said.
I'll remove HQL page (and current code) to HRDF sub-page with HRDF
re-arrangement, soon.

Our preparations are complete.
Remove the hql package, and fix the Shell.java for Hbase at anytime.

On 3/6/08, Edward Yoon (JIRA) <jira@apache.org> wrote:
>    [ https://issues.apache.org/jira/browse/HBASE-487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12575547#action_12575547
> Edward Yoon commented on HBASE-487:
> -----------------------------------
> Hmm. I See. and agree about flexibility.
> Then, i'd like to move current HQL features to HRdfStore project. (http://wiki.apache.org/incubator/HRdfStoreProposal)
> It makes more sense for us, and HQL features are good fit with HRdfStore project.
> Would you sponsor me and HRdfStore project?
> > 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
> >            Priority: Minor
> >
> > 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.

B. Regards,
Edward yoon @ NHN, corp.

View raw message