HQL character is quite different from Hbase, like you said. I'll remove HQL page (and current code) to HRDF sub-page with HRDF re-arrangement, soon.
Our preparations are complete. Remove the hql package, and fix the Shell.java for Hbase at anytime. On 3/6/08, Edward Yoon (JIRA) <[EMAIL PROTECTED]> wrote: > > [ > https://issues.apache.org/jira/browse/HBASE-487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12575547#action_12575547 > ] > > Edward Yoon commented on HBASE-487: > ----------------------------------- > > Hmm. I See. and agree about flexibility. > Then, i'd like to move current HQL features to HRdfStore project. > (http://wiki.apache.org/incubator/HRdfStoreProposal) > It makes more sense for us, and HQL features are good fit with HRdfStore > project. > > Would you sponsor me and HRdfStore project? > > > > 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 > > Priority: Minor > > > > 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. > > -- B. Regards, Edward yoon @ NHN, corp.
