[ https://issues.apache.org/jira/browse/HBASE-5548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13230853#comment-13230853 ]
Jesse Yates commented on HBASE-5548: ------------------------------------ Oh, and for completeness, here is what the output now looks like: {code} 1.9.2-p290 :002 > list TABLE 0 row(s) in 0.0300 seconds 1.9.2-p290 :003 > t = create 't', 'f' 0 row(s) in 1.0970 seconds => #<Hbase::Table:0x6601879b @table=#<Java::OrgApacheHadoopHbaseClient::HTable:0x5b489c06>, @shell=#<Shell::Shell:0x3bba1894 @formatter=#<Shell::Formatter::Console:0x36a3bb2e @out=Kernel, @row_count=0, @max_width=113>, @hbase_admin=#<Hbase::Admin:0x3755e508 @zk_wrapper=#<#<Class:0x682f8c99>:0x45ed957d>, @zk_main=#<Java::OrgApacheZookeeper::ZooKeeperMain:0x385715>, @formatter=#<Shell::Formatter::Console:0x36a3bb2e @out=Kernel, @row_count=0, @max_width=113>, @conf=#<Java::OrgApacheHadoopConf::Configuration:0x73c28517>, @admin=#<Java::OrgApacheHadoopHbaseClient::HBaseAdmin:0x2a717ef5>>, @hbase=#<Hbase::Hbase:0x21ff3fcf @configuration=#<Java::OrgApacheHadoopConf::Configuration:0x73c28517>>>> 1.9.2-p290 :004 > t.put 'r', 'f', 'v' 1.9.2-p290 :005 > t.scan ROW COLUMN+CELL r column=f:, timestamp=1331865816290, value=v 1 row(s) in 0.0520 seconds 1.9.2-p290 :006 > t.help 'scan' Scan a table; pass table name and optionally a dictionary of scanner specifications. Scanner specifications may include one or more of: TIMERANGE, FILTER, LIMIT, STARTROW, STOPROW, TIMESTAMP, MAXLENGTH, or COLUMNS. If no columns are specified, all columns will be scanned. To scan all members of a column family, leave the qualifier empty as in 'col_family:'. The filter can be specified in two ways: 1. Using a filterString - more information on this is available in the Filter Language document attached to the HBASE-4176 JIRA 2. Using the entire package name of the filter. Some examples: hbase> scan '.META.' hbase> scan '.META.', {COLUMNS => 'info:regioninfo'} hbase> scan 't1', {COLUMNS => ['c1', 'c2'], LIMIT => 10, STARTROW => 'xyz'} hbase> scan 't1', {COLUMNS => 'c1', TIMERANGE => [1303668804, 1303668904]} hbase> scan 't1', {FILTER => "(PrefixFilter ('row2') AND (QualifierFilter (>=, 'binary:xyz'))) AND (TimestampsFilter ( 123, 456))"} hbase> scan 't1', {FILTER => org.apache.hadoop.hbase.filter.ColumnPaginationFilter.new(1, 0)} For experts, there is an additional option -- CACHE_BLOCKS -- which switches block caching for the scanner on (true) or off (false). By default it is enabled. Examples: hbase> scan 't1', {COLUMNS => ['c1', 'c2'], CACHE_BLOCKS => false} Also for experts, there is an advanced option -- RAW -- which instructs the scanner to return all cells (including delete markers and uncollected deleted cells). This option cannot be combined with requesting specific COLUMNS. Disabled by default. Example: hbase> scan 't1', {RAW => true, VERSIONS => 10} Scan can also be used directly from a table, by first getting a reference to a table, like such: hbase> t = get_table 't' hbase> t.scan Note in the above situation, you can still provide all the filtering, columns, options, etc as described above. 1.9.2-p290 :007 > {code} > Add ability to get a table in the shell > --------------------------------------- > > Key: HBASE-5548 > URL: https://issues.apache.org/jira/browse/HBASE-5548 > Project: HBase > Issue Type: Improvement > Components: shell > Reporter: Jesse Yates > Assignee: Jesse Yates > Fix For: 0.96.0 > > Attachments: ruby_HBASE-5528-v0.patch, ruby_HBASE-5548-v1.patch, > ruby_HBASE-5548-v2.patch > > > Currently, all the commands that operate on a table in the shell first have > to take the table as name as input. > There are two main considerations: > * It is annoying to have to write the table name every time, when you should > just be able to get a reference to a table > * the current implementation is very wasteful - it creates a new HTable for > each call (but reuses the connection since it uses the same configuration) > We should be able to get a handle to a single HTable and then operate on that. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira