Return-Path: X-Original-To: apmail-drill-dev-archive@www.apache.org Delivered-To: apmail-drill-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 31CB518529 for ; Mon, 4 May 2015 20:19:32 +0000 (UTC) Received: (qmail 91729 invoked by uid 500); 4 May 2015 20:19:32 -0000 Delivered-To: apmail-drill-dev-archive@drill.apache.org Received: (qmail 91676 invoked by uid 500); 4 May 2015 20:19:31 -0000 Mailing-List: contact dev-help@drill.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@drill.apache.org Delivered-To: mailing list dev@drill.apache.org Received: (qmail 91664 invoked by uid 99); 4 May 2015 20:19:31 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 04 May 2015 20:19:31 +0000 X-ASF-Spam-Status: No, hits=3.2 required=5.0 tests=HTML_MESSAGE,SPF_SOFTFAIL X-Spam-Check-By: apache.org Received-SPF: softfail (nike.apache.org: transitioning domain of dbarclay@maprtech.com does not designate 54.76.25.247 as permitted sender) Received: from [54.76.25.247] (HELO mx1-eu-west.apache.org) (54.76.25.247) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 04 May 2015 20:19:03 +0000 Received: from mail-pa0-f51.google.com (mail-pa0-f51.google.com [209.85.220.51]) by mx1-eu-west.apache.org (ASF Mail Server at mx1-eu-west.apache.org) with ESMTPS id 21391253FC for ; Mon, 4 May 2015 20:19:02 +0000 (UTC) Received: by pabtp1 with SMTP id tp1so170239671pab.2 for ; Mon, 04 May 2015 13:18:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:organization:user-agent :mime-version:to:subject:references:in-reply-to:content-type; bh=8ZgJwVx6fBsArvICKTPMNRVKZfstDmPFs3ImTccMyjs=; b=O//Iygvoicbun1dqSMJMJv6sv40olHLyRvQRTHTbAyM+FVt5IsnEkluEiTnygXiOBn +KDI4J1OlGnCrBfday7JfmAUimzRwrNxodQElkdoLLZkssMViHY85tk4mDT2EB4QlCij Wm3SUkGWsKafOfJNBk2aQSSrewsW3aCjfgPDhsnVvuLxdoQLTuo10pJ+BtAMCuzaXfAf eCY397ZA8zyY7gA4BbeZV5bfYku7ClV7FnHBOYVe87tb39iO0B1f151i7wIRVr9dWqOz Kcy8tWcDudo/I/q8d4K91yF0uj+b3BrBCWeX/0IMkHCyAvVaENs3HaNGcWHu+BTeQdBM ukwA== X-Gm-Message-State: ALoCoQnX+vtZ4c5UeLCGfBekBPz3yznqBxx2o2S+hUimQtC/A3S1wYVw/jOMah8VueosMn7Lrrcv X-Received: by 10.66.66.135 with SMTP id f7mr24855037pat.22.1430770734128; Mon, 04 May 2015 13:18:54 -0700 (PDT) Received: from [10.250.52.36] ([12.220.154.66]) by mx.google.com with ESMTPSA id dc8sm13671035pdb.23.2015.05.04.13.18.50 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 04 May 2015 13:18:52 -0700 (PDT) Message-ID: <5547D428.3080706@maprtech.com> Date: Mon, 04 May 2015 13:18:48 -0700 From: Daniel Barclay Organization: MapR Technologies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0 SeaMonkey/2.32.1 MIME-Version: 1.0 To: dev@drill.apache.org Subject: Re: RecordBatchLoader.load(...) SchemaChangeException References: <5547BC8E.6050702@maprtech.com> In-Reply-To: <5547BC8E.6050702@maprtech.com> Content-Type: multipart/alternative; boundary="------------070105030500070103010103" X-Virus-Checked: Checked by ClamAV on apache.org --------------070105030500070103010103 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit To clarify: load(...) returns a boolean value to indicate whether there was a schema change. Initially, I thought that throwing SchemaChangeException was an old way of indicating a schema change, and so thought that the throws declaration and various catches were obsolete. However, reportedly SchemaChangeException is or was for reporting /problems/ in making schema changes, not for reporting normal schema changes. Therefore, the code is not /necessarily /as obsolete as I initially thought. With that clarification, I re-submit the question: I wrote: > In RecordBatchLoader, the load(...) method is declared to throw > SchemaChangeException, but it never actually throws SchemaChangeException. > > It supposed to be declared to throw SchemaChangeException? (E.g., are we > reserving the "right" for load(...) to throw that, and declaring "throws > SchemaChangeException" to help make sure callers already handle it in case > load(...) later changes to actually throw it sometimes?) > > Or is that "throws" a remnant that should be removed sometime? > > > Daniel -- Daniel Barclay MapR Technologies --------------070105030500070103010103--