[
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
