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 <tarmstr...@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.b...@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 <mi...@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 <l...@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
> > > >
> > >
> >
>

Reply via email to