hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "stack (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HBASE-487) Replace hql w/ a hbase-friendly jirb or jython shell
Date Tue, 17 Jun 2008 23:56:45 GMT

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

stack commented on HBASE-487:

New commit on this issue.  Comments below.  All methods are in place as of this commit.  Need
to do a little more testing before closing.

M  src/test/org/apache/hadoop/hbase/TestBloomFilters.java
  Constant named changed From DEFAULT_MAX_VALUE_LENGTH to DEFAULT_LENGTH
M  src/java/org/apache/hadoop/hbase/HColumnDescriptor.java
  Changed MAX_LENGTH to LENGTH and dropped MAX from DEFAULT_MAX_LENGTH
M src/java/org/apache/hadoop/hbase/HConstants.java
M  src/java/org/apache/hadoop/hbase/regionserver/HStore.java
  Make the delete of data file recursive; when its not, just fails because
  data file exists
M  src/java/org/apache/hadoop/hbase/regionserver/NoSuchColumnFamilyException.java
  Don't retry these exceptions.
M  src/java/org/apache/hadoop/hbase/HRegionInfo.java
  NAME define moved to HConstants
M  src/java/org/apache/hadoop/hbase/master/TableOperation.java
  Pass String to TNFE rather than byte array.
M  src/java/org/apache/hadoop/hbase/io/Cell.java
  Add constructor that takes a String
M  src/java/org/apache/hadoop/hbase/io/BatchOperation.java
  Add Constructor that takes String
M  src/java/org/apache/hadoop/hbase/client/HTable.java
  Add timestamp argument to the deleteFamily methods.
M  src/java/org/apache/hadoop/hbase/client/HConnectionManager.java
  toString byte arrays in exception construction
M  bin/HBase.rb
  Moved java includes here out of hirb.
  Added bunch of defines.
  Added implementations for scan, delete*, put, get, etc.  
  Added little test suite.
M  bin/Formatter.rb
M  bin/hirb.rb
  Filled out help and filled out missing methods.

> 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: 487-added-formatter.patch, better-hirb.patch, groovy-2.patch, groovy.patch,
jruby.patch, module_in_bin.patch, rb.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.

View raw message