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 3051 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. This is causing the checksetup tinderbox to burn.
It turns out that all over checksetup we assume that the milestones table already exists, and it has a milestone.products field if it's old. This assumption doesn't hold true for 2.8. I think the best solution at this point is to drop support for upgrading from 2.8. This would allow us to remove some code elsewhere in Bugzilla, too.
that's no fun :(
*** Bug 254970 has been marked as a duplicate of this bug. ***
<justdave> 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 OK, that's what I'll do. :-)
For the record, bug 43600 is the bug that broke this.
*** This bug has been marked as a duplicate of 277277 ***
Yeah, further investigation shows that this bug is not a duplicate. In one condition, we're upgrading from 2.8, so our milestones table is empty. We have a bugs.product field, but a milestones.product_id field. That's something that needs to be fixed. In the bug that this was duped to, the user has somehow accidentally truncated the milestones table, and then our code thinks that it was just created. That's a less significant issue, because it's a user error. It's also much more difficult to fix.
Oh, arrgh. :-) They are separate bugs, but I realized that I can fix them both with one patch. :-)
Turns out that there are other issues: DBD::mysql::st execute failed: Unknown column 'blessgroupset' in 'where clause' [for Statement "SELECT userid FROM profiles WHERE (blessgroupset & 1) != 0"] at ./checksetup.pl line 2999 So I feel like the issues belong more appropriately in this bug, now.
Created attachment 178012 [details] [diff] [review] Make checksetup work on 2.8 OK, this works. I verified that I can log into and use the Bugzilla that this creates. I can file bugs, search for things, etc. You can probably create a 2.8 database by checking out revision 1.25 of checksetup .pl, if you really want to test it -- I think that's around the right time.
Comment on attachment 178012 [details] [diff] [review] Make checksetup work on 2.8 I don't want to install 2.8, but what I read looks right and doesn't break anything (I have gone through previous checksetup.pl files such as the ones in 2.8, 2.10, 2.16 and 2.18). Nice work! :) r=LpSolit
mkanat, this patch does not apply cleanly to 2.18. Please backport this patch.
Created attachment 178190 [details] [diff] [review] Backport to 2.18 OK, here's the backport. I've tested this and it also works. The code is slightly different, of course, because the functions are differently named in 2.18.
Comment on attachment 178190 [details] [diff] [review] Backport to 2.18 r=LpSolit
Tip: /cvsroot/mozilla/webtools/bugzilla/checksetup.pl,v <-- checksetup.pl new revision: 1.378; previous revision: 1.377 done 2.18: Checking in checksetup.pl; /cvsroot/mozilla/webtools/bugzilla/checksetup.pl,v <-- checksetup.pl new revision: 1.289.2.31; previous revision: 1.289.2.30 done