[
https://issues.apache.org/jira/browse/HBASE-487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12599439#action_12599439
]
Bryan Duxbury commented on HBASE-487:
-------------------------------------
For sure the simplest way to do the colfam spec would be to use JRuby hashes,
which have the form of {"key" => "value"}. That's what the => operator is used
for. If that doesn't put people off, then I think it's what we should use for
all *_spec objects in this dsl.
Truncate can be a nice to have. I agree there should be a describe in general,
so let's add that as the first step. "describe table columnfamily" seems
redundant to me - let's just go with "describe table", and you get the full
table spec including columns.
I think regex in get is a nice to have for the next version.
Some sample output might look like (excuse the hacky ascii boxing):
{code}
irb>get "my_table", "colfam:name"
+------------------+---------+
| column | value |
+------------------+---------+
| colfam:name | bryan |
+------------------+---------+
Completed in 0.01 sec.
irb>
{code}
Mind you, the cool looking table would be the toString of whatever object was
actually returned, which would probably be some wrapper around RowResult. What
do you mean, how is it specified for a session?
> Otherwise, looks good. Intent is to use verbs from current hbase API rather
> than sql-ese?
Yes, and this is very, very important distinction. The goal is to map as much
of this shell as possible to the API, rather than trying to make it look like
SQL. I want people to have to stop and think at least a little about the
differences, rather than just assuming off the bat there's some magical SELECT
verb that takes care of everything.
> 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
>
>
> 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.
