[
https://issues.apache.org/jira/browse/HBASE-487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12589622#action_12589622
]
stack commented on HBASE-487:
-----------------------------
Couple of notes on my groovy playing:
+ Groovysh is hard to modify. Not subclassable -- has a main -- and so I have
to copy at least two groovy shell files local -- Main and Groovysh -- and
change a few lines like package and class names.
+ Groovysh is hard to modify in that the list of commands displayed in shell
are listed in a bundled commands.xml file. The commands.xml is loaded as a
resource from the current .groovy files classloader. Means I have to bring the
commands.xml local too.
+ Looks like I cannot do without parens invoking groovy methods. Works if you
do this 'get tableName:"SOME_TABLE", rowName: "SOME_ROW"' but not if I do this
'rowresult = get tableName:"SOME_TABLE", rowName: "SOME_ROW"': i.e. the parse
gets messed up by the 'rowresult =' prefix.
Idea for how hbase groovy would work is roughly:
+ On startup you'd have a shell that had an hbase object in it.
+ If you did a help, you'd see list of groovy options with addition of hbase
object.
+ You'd do 'help hbase' and it would list something like this:
{code}
hbase.admin
hbase.conf
hbase.get
hbase.iterator
hbase.put
{code}
+ Doing 'help hbase.admin' would show you something like:
{code}
hbase.admin.createTable ...
hbase.admin.deleteTable ...
hbase.admin.tables
...
{code}
+ Invoking something like hbase.admin.createTable, you could pass a populated
HTableDescriptor or you could do short-circuit that was something like:
'hbase.admin.createTable("table_name", "colfamily1_name", ....)
Replacing shell with groovy will take a while -- few days to get something
primitive into place and then ongoing work improving.
> 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
> Attachments: groovy-2.patch, groovy.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.
