277277 - checksetup fails when the milestones table is empty

Status: RESOLVED FIXED

(Bugzilla :: Installation & Upgrading, defect)

Description

[Kevin Benton]

Checksetup.pl attempts to query against non-existant bugs.product field when no
milestones are listed in the DB.  Should have been changed to bugs.product_id
wheen the field was renamed.  This is a show-stopper for anyone who is not using
milestones.

Comment 1

[Kevin Benton]

Attachment: Patch to fix specific case where no milestones are listed but checksetup.pl attempts to access bugs.product field

This bug has not been tested in Tinderbox, nor have I checked to see if there
are any other cases where product was changed to product_id.  The error message
I was getting prior to this change was:

Replacing blank milestones...
DBD::mysql::st execute failed: Unknown column 'product' in 'field list' at
./checksetup.pl line 2963.
Populating milestones table...
DBD::mysql::st fetchrow_array failed: fetch() without execute() at
./checksetup.pl line 2969.

After this patch, checksetup.pl successfully runs to completion.

Comment 2

[Frédéric Buclin]

Comment on attachment 170464 [details] [diff] [review]
Patch to fix specific case where no milestones are listed but checksetup.pl attempts to access bugs.product field

From what I understand, the 'product' column still exists in the 'bugs' table
at line 2971. Its content is converted to its product ID at line 3417 and the
'product' column is deleted at line 3465.

I think that checksetup.pl assumes that if the milestone table is empty, it
means that the 'product' column still exists in the 'bugs' table, which may be
wrong if the admin has manually deleted the 'milestone' table for some reason
or because something else happened.

Maybe the right patch would be to check if the 'product' column exists? If yes,
that's fine; else the 'milestone' table has to be filled from informations in
the 'product_id' column.

zach?

Comment 3

[Kevin Benton]

I can see I may want to "if GetFieldDef('bugs', 'product') {" then convert the
data to bugs.product_id format, but my concern is how to do that properly.  Any
suggestions?  I want to make sure that my conversion doesn't interfere with
later uses of the bugs.product field.

Comment 4

[Max Kanat-Alexander]

I've seen this happen on an upgrade from 2.8 on landfill.

DBD::mysql::st execute failed: Unknown column 'product' in 'where clause' [for
Statement "SELECT value FROM milestones WHERE value = '---' AND product =
'TestProduct'"] at ./checksetup.pl line 3019

Comment 5

[Max Kanat-Alexander]

OK, my bug above (which is causing tinderbox to burn on the checksetup test) is
actually a different bug than the one originally reported.

The problem is that 2.8 has no milestones table. So it's created with a
"product_id" column, not a product column.

I think the problem is that table *creation*, unlike table changes, does not
happen in time sequence, but all at the beginning. So when we're running that
part of the script, the target_milestone table has a product_id field, not a
product field.

Comment 6

[Max Kanat-Alexander]

OK, I can reproduce this bug:

DBD::mysql::st execute failed: Unknown column 'product' in 'field list' [for
Statement "SELECT DISTINCT target_milestone, product FROM bugs"] at
./checksetup.pl line 3033

The problem is that the condition above that code is sort of wrong. It runs if I
ever "TRUNCATE TABLE milestones".

Comment 7

[Dave Miller [:justdave]]

*** Bug 283403 has been marked as a duplicate of this bug. ***

Comment 8

[Dave Miller [:justdave]]

This is a regression caused by bug 43600.

From bug 283403:

the easy fix I think, is to trigger on something else that happened
near the time the milestones table was created, and revert that table to the
original schema if that trigger happens

Comment 9

[Max Kanat-Alexander]

This is a different bug than bug 283403, but it's possible (though not
definitely certain) that the fixes are the same.

Comment 10

[Max Kanat-Alexander]

By the way, the reason that I put this at minor was that it requires an admin
manually mucking with the database, and truncating the milestones table in order
for this to happen.

The blocker fixes it. We won't properly re-populate the milestones table if a
silly admin truncates it, but checksetup also won't die if the milestones table
has been truncated. Or at least, it won't throw the error seen in this bug.