hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Yu <yuzhih...@gmail.com>
Subject Re: updating shell functionality
Date Tue, 22 Nov 2011 18:48:49 GMT
Interesting idea.

See the following for reference:
http://asqyzeron.wordpress.com/2007/01/14/toying-with-the-dynamic-features-of-ruby-adding-methods-at-run-time/
http://www.vitarara.org/cms/ruby_metaprogamming_declaratively_adding_methods_to_a_class

On Tue, Nov 22, 2011 at 10:34 AM, Jesse Yates <jesse.k.yates@gmail.com>wrote:

> Hey all,
>
> I'm trying to take some time to figure out the right way to do support to
> future 'pluggable' features/extensions to modifying tables. Specially, I'm
> thinking about the 'alter' command, but in the future, this model could be
> applied to other facets of the shell.
>
>  In the easiest, and hackiest) way, we could just take in the full class
> name to call and then lookup the java class, but I like Gary's comment
> from HBASE-4605
> (Constraints) <https://issues.apache.org/jira/browse/HBASE-4605>:
>
> "3. provide a extensions dir for the shell:
>
>   - extensions drop a simple jruby scriptlet in a file in the dir (say
>   lib/ruby/hbase/ext)
>   - the scriptlet does some simple registration of the available
>   methods/commands
>   - the shell code loads all files"
>
> In doing this a 'clean' way, we could also do a lot in making the shell
> easier to use. (Stick with me, its gets a little verbose here).
>
> What I'm proposing is that instead of altering tables like this(for setting
> arbitrary keys, but this could be things like MAX_FILESIZE, etc):
>
>  alter 'table', METHOD=>'table_attr', "key1" => "v1"
>
> We could actually have the use make explicit method calls (which should
> give auto-complete in irb) on an object you get from alter. Then you can do
> something like this:
>
>  hbase> alter('table').table_attr "key1" => "v1"
>
> in the simple case. And we allow a lot of the basic functionality you
> already get with Java HTD.
>
> However, this becomes interesting when we want to add more features. For
> instance, with constraints, it would look something like:
>
>  hbase> alter('table').addConstraint('com.my.Constraint')
>
> What's even cooler is, since we can reopen ruby classes and add
> functionality - for instance when we load all the files in the
> lib/ruby/hbase/ext - we are actually open up the object returned by alter
> (maybe something like AlterTable class?) and add methods. This means we
> also get auto-complete when doing an alteration on a table.
>
> This is then a really extensible way to add new functionality and cleanup
> older. The ext scripts just open up the actual classes they need to modify
> to add the method functionality, without all the mucking around with
> strings that we are doing now.
>
> For instance, adding a coprocessor can go from:
>
>  hbase> alter 't1', METHOD =>
>
> 'table_att''coprocessor'=>'hdfs:///foo.jar|com.foo.FooRegionObserver|1001|arg1=1,arg2=2
> to now something like:
>
>  hbase> alter('t1').addCoprocessor 'com.foo.FooRegionObserver',
> 'hdfs:///foo.jar', '1001' {'arg1'=>'1','arg2'=>'2'}
>
>
> Or slightly more verbosely:
>
>  hbase> alter('t1').addCoprocessor('com.foo.FooRegionObserver',
> 'hdfs:///foo.jar', '1001' {'arg1'=>'1','arg2'=>'2'})
>
>
> This approach might also be something we can extend to much of the current
> shell functionality while still retaining much of the current code. I think
> moving this this kind of approach applies anywhere we would need to do
> chaining of invocations. Clearly, it depends on the situation, but
> leveraging OOP, rather than switching on string, makes a lot of sense (at
> least to me :)
>
> What does everyone think of this approach? Am I missing anything
> technically (haven't really played with JRuby before) or historically? Or
> maybe people have other preferences?
>
> Thanks!
>
> -- Jesse
> -------------------
> Jesse Yates
> 240-888-2200
> @jesse_yates
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message