[
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.
{code}
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
Added NAME and VERSIONS
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
Fixup.
M bin/hirb.rb
Filled out help and filled out missing methods.
{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: 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.
