hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse Yates <jesse.k.ya...@gmail.com>
Subject updating shell functionality
Date Tue, 22 Nov 2011 18:34:08 GMT
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
   - the scriptlet does some simple registration of the available
   - 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 =>
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?


-- Jesse
Jesse Yates

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