I know that not now perhaps But eventually. haha But, I'm -1. >> Already-written parser with no need of extension probing deeper into hbase: i.e. better for debugging than HQL could ever be.
I think bugs are almost appeared. and there is no patching permanently. Why do you think it is an advantage? >> Less likely hbase could be confused for a SQL db. HQL syntax can be modified. Why do you think it is an advantage? Also, i don't know why it would be replaced. Just add a jython shell. Is there something problems? (Or Is this a indirect expression of bark away?) On 3/4/08, stack (JIRA) <[EMAIL PROTECTED]> wrote: > 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.
