Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id CA66C200C72 for ; Fri, 12 May 2017 18:50:51 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id C8F29160BB8; Fri, 12 May 2017 16:50:51 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 1AF16160BA8 for ; Fri, 12 May 2017 18:50:50 +0200 (CEST) Received: (qmail 65195 invoked by uid 500); 12 May 2017 16:50:50 -0000 Mailing-List: contact dev-help@impala.incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@impala.incubator.apache.org Delivered-To: mailing list dev@impala.incubator.apache.org Received: (qmail 65181 invoked by uid 99); 12 May 2017 16:50:50 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 12 May 2017 16:50:50 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd2-us-west.apache.org (ASF Mail Server at spamd2-us-west.apache.org) with ESMTP id E00CA1A7B0D for ; Fri, 12 May 2017 16:50:49 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -2.521 X-Spam-Level: X-Spam-Status: No, score=-2.521 tagged_above=-999 required=6.31 tests=[HTML_MESSAGE=2, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=disabled Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id 0KZrO_fpBlI8 for ; Fri, 12 May 2017 16:50:48 +0000 (UTC) Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with SMTP id B1E005F36B for ; Fri, 12 May 2017 16:50:47 +0000 (UTC) Received: (qmail 65166 invoked by uid 99); 12 May 2017 16:50:47 -0000 Received: from mail-relay.apache.org (HELO mail-relay.apache.org) (140.211.11.15) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 12 May 2017 16:50:47 +0000 Received: from mail-yw0-f176.google.com (mail-yw0-f176.google.com [209.85.161.176]) by mail-relay.apache.org (ASF Mail Server at mail-relay.apache.org) with ESMTPSA id 00B8B1A031E for ; Fri, 12 May 2017 16:50:46 +0000 (UTC) Received: by mail-yw0-f176.google.com with SMTP id l14so13790889ywk.1 for ; Fri, 12 May 2017 09:50:46 -0700 (PDT) X-Gm-Message-State: AODbwcDX/1N2K2YiGHPBaxpfM0vBhrBsluEcyyJGwbpG3vU7ayp6y0lm TrXhm/9nNqreaU/kgL4im+fw2o5GPdEo X-Received: by 10.129.79.198 with SMTP id d189mr4038948ywb.47.1494607846056; Fri, 12 May 2017 09:50:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.181.70 with HTTP; Fri, 12 May 2017 09:50:25 -0700 (PDT) In-Reply-To: References: From: Henry Robinson Date: Fri, 12 May 2017 09:50:25 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Should we change tests so they don't use single letter table names? To: dev@impala.incubator.apache.org Content-Type: multipart/alternative; boundary="001a114db2eabf058b054f56819a" archived-at: Fri, 12 May 2017 16:50:52 -0000 --001a114db2eabf058b054f56819a Content-Type: text/plain; charset="UTF-8" Is there any way to scope the tests to their own, unique, database namespace? On 12 May 2017 at 09:26, Lars Volker wrote: > Looking at AnalyzeDDLTest alone it's full of "t", "p", "tbl", "test", > "foo", "bar" and the like. Fixing them often means overflowing a line and > fixing line breaks, so seems a bit more effort. Maybe better to postpone > until after the release. > > On Fri, May 12, 2017 at 6:11 PM, Alexander Behm > wrote: > > > Tim, I think Michael was not suggesting to drop your tables, but instead > > create/drop new unique tables in each test like we do in EE tests. > > > > Yes, I think we should tackle this. I frequently run into this problem > with > > a "foo" table :) > > > > On Fri, May 12, 2017 at 8:59 AM, Lars Volker wrote: > > > > > Yes, they are in the default db. I think the easiest way to go about > this > > > is to create 26 tables in default with a script and then rename tables > in > > > the FE tests until we catch all of them. Or try to grep for the > offending > > > tests. :) > > > > > > There seems to be some consensus that we should tackle this, so I'll > > open a > > > JIRA. > > > > > > On Fri, May 12, 2017 at 5:49 PM, Tim Armstrong < > tarmstrong@cloudera.com> > > > wrote: > > > > > > > Personally I'd prefer the frontend test to fail instead of dropping > my > > > > table without warning. I assume these tables are in the default > > database, > > > > right? > > > > > > > > On Fri, May 12, 2017 at 8:43 AM, Alexander Behm < > > alex.behm@cloudera.com> > > > > wrote: > > > > > > > > > Michael, to keep them fast and self-contained the FE tests do not > > > > require a > > > > > running Impala cluster, and as such cannot really execute any > > > statements > > > > > (e.g. DROP/ADD). > > > > > > > > > > The FE has limited mechanisms for setting up temporary tables which > > > might > > > > > suffice in most but not all cases. > > > > > > > > > > I agree with Lars that we should address this issue. We need to > look > > > at a > > > > > few cases and see if there's a sledgehammer solution we can apply. > > > > > > > > > > On Fri, May 12, 2017 at 7:21 AM, Michael Brown > > > > > wrote: > > > > > > > > > > > Why not alter the frontend test to drop t if exists? Tests should > > > > > generally > > > > > > strive to set themselves up. Is there some trait of the frontend > > > tests > > > > > that > > > > > > prevents that? > > > > > > > > > > > > On Fri, May 12, 2017 at 4:38 AM, Lars Volker > > > wrote: > > > > > > > > > > > > > Hi All, > > > > > > > > > > > > > > I frequently create test tables on my local system with names > > like > > > > "t" > > > > > or > > > > > > > "p". A couple of frontend tests use the same names and then > fail > > > with > > > > > > > "Table already exists". > > > > > > > > > > > > > > Does anyone else hit this from time to time? Can we change the > > > table > > > > > > names > > > > > > > in the tests to avoid single letter names? If there are no > > > > objections, > > > > > > I'll > > > > > > > open a JIRA. > > > > > > > > > > > > > > Thanks, Lars > > > > > > > > > > > > > > > > > > > > > > > > > > > > --001a114db2eabf058b054f56819a--