impala-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Behm <alex.b...@cloudera.com>
Subject Re: Should we change tests so they don't use single letter table names?
Date Fri, 12 May 2017 18:28:45 GMT
Henry, we need to investigate the feasibility of that. There are a ton of
tests and different cases to consider, and we don't want to lose coverage.
The mechanism for scoping to a unique db should be easy.

Lars, definitely not something we should rush.

On Fri, May 12, 2017 at 9:50 AM, Henry Robinson <henry@apache.org> wrote:

> Is there any way to scope the tests to their own, unique, database
> namespace?
>
> On 12 May 2017 at 09:26, Lars Volker <lv@cloudera.com> 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 <alex.behm@cloudera.com>
> > 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 <lv@cloudera.com> 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 <
> mikeb@cloudera.com
> > >
> > > > > 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 <lv@cloudera.com>
> > > > 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
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message