Re: Should we change tests so they don't use single letter table names?

[Alexander Behm]

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  wrote:

> 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 <
> > 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 
> > > > 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
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: Should we change tests so they don't use single letter table names?

[Henry Robinson]

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 <
> 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  >
> > > > 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
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: Should we change tests so they don't use single letter table names?

[Lars Volker]

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 
> > 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 
> > > 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
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: Should we change tests so they don't use single letter table names?

[Alexander Behm]

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 
> 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 
> > 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
> > > > >
> > > >
> > >
> >
>

Re: Should we change tests so they don't use single letter table names?

[Lars Volker]

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 
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 
> 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
> > > >
> > >
> >
>

Re: Should we change tests so they don't use single letter table names?

[Tim Armstrong]

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 
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
> > >
> >
>

Re: Should we change tests so they don't use single letter table names?

[Alexander Behm]

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
> >
>

Re: Should we change tests so they don't use single letter table names?

[Michael Brown]

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
>

Re: Should we change tests so they don't use single letter table names?

[Marcel Kornacker]

That sounds like a good idea. If it's a single-test table, it would
probably be prudent to embed the name of the test.

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
>

Should we change tests so they don't use single letter table names?

[Lars Volker]

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