[
https://issues.apache.org/jira/browse/HBASE-487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12599445#action_12599445
]
stack commented on HBASE-487:
-----------------------------
I'm fine w/ ruby hashes. Fine also w/ no describe table_name col_family in
first version. Same for regex.
Your output is missing row spec. Or, outputting in hql, if row was specified
in query, I would output just column and cell -- no rowspec -- but when say,
scanning, then you needed the three rows. Also missing is timestamp (Now its
available, lets add it to output)
In hql, you could specify a table formatter. There were two types: ascii table
and xhtml (Former was default; latter was used outputting content in the hql ui
page and often useful when you needed to parse a big result). Going forward we
should be able to add other formatter types and formatters (no formatting with
tab delimiters, no column headers, json, etc.) At least ascii and probably
xhtml are needed in the first version I'd say.
Would suggest you clean up your proposal and put it up on
http://wiki.apache.org/hadoop/Hbase/Shell/Replacement or into a new page. Add
your distinction between hql and this dsl somewhere as a bolded design dictate.
> 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.
