Return-Path: X-Original-To: apmail-accumulo-user-archive@www.apache.org Delivered-To: apmail-accumulo-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 05AB8E63E for ; Tue, 22 Jan 2013 16:57:07 +0000 (UTC) Received: (qmail 27698 invoked by uid 500); 22 Jan 2013 16:57:06 -0000 Delivered-To: apmail-accumulo-user-archive@accumulo.apache.org Received: (qmail 27630 invoked by uid 500); 22 Jan 2013 16:57:06 -0000 Mailing-List: contact user-help@accumulo.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@accumulo.apache.org Delivered-To: mailing list user@accumulo.apache.org Received: (qmail 27620 invoked by uid 99); 22 Jan 2013 16:57:06 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 22 Jan 2013 16:57:06 +0000 X-ASF-Spam-Status: No, hits=-0.1 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of David.Slater@jhuapl.edu designates 128.244.251.37 as permitted sender) Received: from [128.244.251.37] (HELO piper.jhuapl.edu) (128.244.251.37) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 22 Jan 2013 16:56:55 +0000 Received: from aplexcas2.dom1.jhuapl.edu (aplexcas2.dom1.jhuapl.edu [128.244.198.91]) by piper.jhuapl.edu with smtp (TLS: TLSv1/SSLv3,128bits,RC4-MD5) id 072c_06bb_9bdc1b77_8d27_43a9_80ab_47f919da447f; Tue, 22 Jan 2013 11:56:33 -0500 Received: from aplesstripe.dom1.jhuapl.edu ([128.244.198.211]) by aplexcas2.dom1.jhuapl.edu ([128.244.198.91]) with mapi; Tue, 22 Jan 2013 11:55:58 -0500 From: "Slater, David M." To: "user@accumulo.apache.org" Date: Tue, 22 Jan 2013 11:55:57 -0500 Subject: Custom Iterators - behavior when switching tablets Thread-Topic: Custom Iterators - behavior when switching tablets Thread-Index: Ac34vuM9W+Frz7XwSaKRW2GpXRPtoA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_AC78983C72177B4D9D1C14F7F4AEBA2143F728A388aplesstripedo_" MIME-Version: 1.0 X-Virus-Checked: Checked by ClamAV on apache.org --_000_AC78983C72177B4D9D1C14F7F4AEBA2143F728A388aplesstripedo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In designing some of my own custom iterators, I was noticing some interesti= ng behavior. Note: my iterator does not return the original key, but instea= d returns a computed value that is not necessarily in lexicographic order. So far as I can tell, when the Scanner switches between tablets, it checks = the key that is returned in the new tablet and compares it (I think it comp= ares key.row()) with the last key from the previous tablet. If the new key = is greater than the previous one, then it proceeds normally. If, however, t= he new key is less than or equal to the previous key, then the Scanner does= not return the value. It does, however, continue to iterate through the ta= blet, continuing to compare until it finds a key greater than the last one.= Once it finds one, however, it progresses through the rest of that tablet = without doing a check. (It implicitly assumes that everything in a tablet w= ill be correctly ordered). Now if I was to return the original key, it would work fine (since it would= always be in order), but that also limits the functionality of my custom i= terator. My primary question is: why would it be designed this way? When switching b= etween tablets, are there potential problems that might crop up if this che= ck isn't done? Thanks, David --_000_AC78983C72177B4D9D1C14F7F4AEBA2143F728A388aplesstripedo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In designing som= e of my own custom iterators, I was noticing some interesting behavior. Not= e: my iterator does not return the original key, but instead returns a comp= uted value that is not necessarily in lexicographic order.

 

So far as I ca= n tell, when the Scanner switches between tablets, it checks the key that i= s returned in the new tablet and compares it (I think it compares key.row()= ) with the last key from the previous tablet. If the new key is greater tha= n the previous one, then it proceeds normally. If, however, the new key is = less than or equal to the previous key, then the Scanner does not return th= e value. It does, however, continue to iterate through the tablet, continui= ng to compare until it finds a key greater than the last one. Once it finds= one, however, it progresses through the rest of that tablet without doing = a check. (It implicitly assumes that everything in a tablet will be correct= ly ordered).

 

Now if I was to return the original key, it would work fine= (since it would always be in order), but that also limits the functionalit= y of my custom iterator.

 

My primary question is: why would it be designe= d this way? When switching between tablets, are there potential problems th= at might crop up if this check isn’t done?

 

Thanks,
David

= --_000_AC78983C72177B4D9D1C14F7F4AEBA2143F728A388aplesstripedo_--