[ 
https://issues.apache.org/jira/browse/HBASE-487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12599390#action_12599390
 ] 

Bryan Duxbury commented on HBASE-487:
-------------------------------------

Ok, I finally found 15 minutes in which to write the dsl spec I've been 
promising. Here it is!

{code}
--General--
help
  Get a list of all possible commands

help [cmd]
  Get deeper help on a specific command

--Admin--

list
  List all the currently existing tables (and their status?)
  
create name, colfam_spec [, colfam_spec ...], [table_opts]
  Create a table.
  
drop name
  Delete a table
  
alter name [, colfam_spec ...] [, table_opts]
  Change an existing table's options or column families
  
enable name
  Enable a table
  
disable name
  Disable a table
  
truncate name
  Drop and recreate a table, effectively emptying it.
  
--DML--
get table_name, row_key [, "column_name" ...]
  Return data from a row
  
put table_name, row_key [, timestamp], "column_name" => "new value", ...
  Put some data to a row at the specific cells, optionally with a timestamp
  
scan table_name, start_key, end_key [, timestamp] [, "column_name" ...]
  Perform a scan over the table from start_key to end_key optionally with a 
timestamp or specified columns.
  
delete table_name, row_key, [, timestamp], "column_name", ...
  Delete the data at the cells provided for a given row

{code}

> 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.

Reply via email to