Return-Path: X-Original-To: apmail-hbase-dev-archive@www.apache.org Delivered-To: apmail-hbase-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 455AF7B7C for ; Mon, 18 Jul 2011 20:16:04 +0000 (UTC) Received: (qmail 21211 invoked by uid 500); 18 Jul 2011 20:16:03 -0000 Delivered-To: apmail-hbase-dev-archive@hbase.apache.org Received: (qmail 21167 invoked by uid 500); 18 Jul 2011 20:16:03 -0000 Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@hbase.apache.org Delivered-To: mailing list dev@hbase.apache.org Received: (qmail 21159 invoked by uid 99); 18 Jul 2011 20:16:02 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 18 Jul 2011 20:16:02 +0000 X-ASF-Spam-Status: No, hits=1.8 required=5.0 tests=FREEMAIL_FROM,FREEMAIL_REPLY,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of saint.ack@gmail.com designates 209.85.214.169 as permitted sender) Received: from [209.85.214.169] (HELO mail-iw0-f169.google.com) (209.85.214.169) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 18 Jul 2011 20:15:55 +0000 Received: by iwn8 with SMTP id 8so4321237iwn.14 for ; Mon, 18 Jul 2011 13:15:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=RSQJZTAnE+u1+CwHaTSQ+CsRQqFsmO4QCB6jJBH7itY=; b=dNdotHF86qJD1Co0/OLfqTtwqvboKzr50LdN0/FqEx9niTn/t72CDRQYs0g1DW6VbM lm2Myox5nE+qzRMkPRJZFS/geQD6QoaahXSpYgfC8ClosM05YCwj/mBUU2ZLTsJB93n4 qG1smSo3R5lQP4Uir9wow9DFTQzxjFpXc2m8Y= Received: by 10.43.62.13 with SMTP id wy13mr7407790icb.342.1311020134783; Mon, 18 Jul 2011 13:15:34 -0700 (PDT) Received: from [10.121.205.76] ([166.205.138.160]) by mx.google.com with ESMTPS id f14sm3371627icm.15.2011.07.18.13.15.33 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 18 Jul 2011 13:15:34 -0700 (PDT) References: In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8J2) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Message-Id: Cc: "dev@hbase.apache.org" X-Mailer: iPhone Mail (8J2) From: Stack Subject: Re: Scanning .META. with start/stop row Date: Mon, 18 Jul 2011 13:15:26 -0700 To: "dev@hbase.apache.org" That would be better yes Good stuff On Jul 18, 2011, at 9:42, Todd Lipcon wrote: > Yea, it used to throw some IllegalArgumentException. Now, I guess it just > gives the wrong result. > > Should shell compensate or should we fix the underlying issue? It seems we > could probably tweak the comparator to deal with the case when one of the > comparison operands has no commas. > > -Todd > > On Mon, Jul 18, 2011 at 9:34 AM, Stack wrote: > >> Ugh. I should have remembered this. Shell should probably compensate >> when the target of scan is one of the catalog tables. Good on you >> Todd, >> St.Ack >> >> On Sun, Jul 17, 2011 at 11:22 PM, Lars George >> wrote: >>> Wow, awesome Todd: >>> >>> hbase(main):004:0> scan '.META.', {STARTROW => 'testtable2', LIMIT => 1} >>> ROW COLUMN+CELL >>> 2011-07-17T23:20:45.480-0700: 58.760: [GC 58.760: [ParNew: >> 19136K->2112K(19136K), 0.0098980 secs] 21990K->6759K(83008K), 0.0099430 >> secs] [Times: user=0.05 sys=0.00, real=0.01 secs] >>> TestTable,,1294648777729.1c1644f4a column=info:regioninfo, >> timestamp=1294648777898, value=REGION => {NAME => >> 'TestTable,,1294648777729.1c >>> 1304442d9c8483a6d167d48. 1644f4a1304442d9c8483a6d167d48.', >> STARTKEY => '', ENDKEY => '', ENCODED => 1c1644f4a1304442d9c8483a6d1 >>> 67d48, TABLE => {{NAME => 'TestTable', >> FAMILIES => [{NAME => 'col1', BLOOMFILTER => 'NONE', REPLICATIO >>> N_SCOPE => '0', COMPRESSION => 'NONE', >> VERSIONS => '3', TTL => '2147483647', BLOCKSIZE => '65536', IN_ >>> MEMORY => 'false', BLOCKCACHE => >> 'true'}]}} >>> ... >>> 1 row(s) in 0.3990 seconds >>> >>> hbase(main):005:0> scan '.META.', {STARTROW => 'testtable2,,', LIMIT => >> 1} >>> ROW COLUMN+CELL >>> testtable2,,1310754563673.d720f2ae column=info:regioninfo, >> timestamp=1310754573539, value=REGION => {NAME => >> 'testtable2,,1310754563673.d >>> 6a4aec4fce746f6a9c1376e3. 720f2ae6a4aec4fce746f6a9c1376e3.', >> STARTKEY => '', ENDKEY => 'row-10', ENCODED => d720f2ae6a4aec4fce74 >>> 6f6a9c1376e3, TABLE => {{NAME => >> 'testtable2', FAMILIES => [{NAME => 'family', BLOOMFILTER => 'NONE', >>> REPLICATION_SCOPE => '0', COMPRESSION >> => 'NONE', VERSIONS => '3', TTL => '2147483647', BLOCKSIZE => '6 >>> 5536', IN_MEMORY => 'false', >> BLOCKCACHE => 'true'}]}} >>> ... >>> 1 row(s) in 0.0440 seconds >>> >>> This also makes the STOPROW work: >>> >>> hbase(main):006:0> scan '.META.', {STARTROW => 'testtable2,,', STOPROW => >> 'testtable3'} >>> ROW COLUMN+CELL >>> 0 row(s) in 0.0220 seconds >>> >>> hbase(main):007:0> scan '.META.', {STARTROW => 'testtable2,,', STOPROW => >> 'testtable3,,'} >>> ROW COLUMN+CELL >>> testtable2,,1310754563673.d720f2ae column=info:regioninfo, >> timestamp=1310754573539, value=REGION => {NAME => >> 'testtable2,,1310754563673.d >>> 6a4aec4fce746f6a9c1376e3. 720f2ae6a4aec4fce746f6a9c1376e3.', >> STARTKEY => '', ENDKEY => 'row-10', ENCODED => d720f2ae6a4aec4fce74 >>> 6f6a9c1376e3, TABLE => {{NAME => >> 'testtable2', FAMILIES => [{NAME => 'family', BLOOMFILTER => 'NONE', >>> REPLICATION_SCOPE => '0', COMPRESSION >> => 'NONE', VERSIONS => '3', TTL => '2147483647', BLOCKSIZE => '6 >>> 5536', IN_MEMORY => 'false', >> BLOCKCACHE => 'true'}]}} >>> ... >>> testtable2,row-10,1310754563677.81 column=info:regioninfo, >> timestamp=1310754573667, value=REGION => {NAME => >> 'testtable2,row-10,131075456 >>> 73e0623a0f82c5b308790737900b60. >> 3677.8173e0623a0f82c5b308790737900b60.', STARTKEY => 'row-10', ENDKEY => >> 'row-20', ENCODED => 8173e062 >>> 3a0f82c5b308790737900b60, TABLE => >> {{NAME => 'testtable2', FAMILIES => [{NAME => 'family', BLOOMFILTER >>> => 'NONE', REPLICATION_SCOPE => '0', >> COMPRESSION => 'NONE', VERSIONS => '3', TTL => '2147483647', BLO >>> CKSIZE => '65536', IN_MEMORY => >> 'false', BLOCKCACHE => 'true'}]}} >>> ... >>> >>> So it is caused by the same issue. Should be fixed, right? >>> >>> Lars >>> >>> >>> On Jul 18, 2011, at 4:36 AM, Todd Lipcon wrote: >>> >>>> Try with STARTROW => "testtable2,,"? >>>> I seem to remember some weirdness about the start/stop row having to >> have >>>> the meta "format" with commas, etc >>>> >>>> -Todd >>>> >>>> On Fri, Jul 15, 2011 at 2:01 PM, Stack wrote: >>>> >>>>> On Fri, Jul 15, 2011 at 11:40 AM, Lars George >>>>> wrote: >>>>>> Using the start row, it prints the entire META. >>>>> >>>>> Starting with the STARTROW. >>>>> >>>>>> Setting a stop row it does >>>>>> not print a single row: >>>>> >>>>> >>>>> Yeah. I see that too in 0.90.3. >>>>> >>>>> St.Ack >>>>> >>>>>> >>>>>> hbase(main):003:0> scan '.META.', { STARTROW => 'testtable2', STOPROW >> => >>>>>> 'testtable3' } >>>>>> ROW COLUMN+CELL >>>>>> >>>>>> 0 row(s) in 0.0220 seconds >>>>>> >>>>>> I have a testtable2 in this case. Am I stuffing up the syntax? >>>>>> >>>>>> Lars >>>>>> >>>>>> On Fri, Jul 15, 2011 at 8:36 PM, Stack wrote: >>>>>> >>>>>>> Passing 'STARTROW' in 0.90.3 seems to work. What you see Lars? >>>>>>> St.Ack >>>>>>> >>>>>>> On Fri, Jul 15, 2011 at 11:31 AM, Lars George >> >>>>>>> wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> I am on 0.90.1 (CDH3u0) but noticed that on trunk as well: doing >> scan >>>>> of >>>>>>>> .META. using a start and stop row does not work. The start row does >>>>>>> nothing, >>>>>>>> i.e. all is shown, and setting the stop row is the opposite, i.e. >>>>> nothing >>>>>>> is >>>>>>>> shown. Is that borked? >>>>>>>> >>>>>>>> Lars >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> Todd Lipcon >>>> Software Engineer, Cloudera >>> >>> >> > > > > -- > Todd Lipcon > Software Engineer, Cloudera