checksetup fails to upgrade from Bugzilla 2.8

RESOLVED FIXED in Bugzilla 2.18

Status

()

Bugzilla
Installation & Upgrading
P1
critical
RESOLVED FIXED
13 years ago
13 years ago

People

(Reporter: Max Kanat-Alexander, Assigned: Max Kanat-Alexander)

Tracking

({regression})

2.19.2
Bugzilla 2.18
regression
Bug Flags:
approval +
blocking2.20 +
approval2.18 +
blocking2.18.1 +

Details

Attachments

(2 attachments)

(Assignee)

Description

13 years ago
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.
(Assignee)

Comment 1

13 years ago
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.

Comment 2

13 years ago
that's no fun :(
(Assignee)

Comment 3

13 years ago
*** Bug 254970 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 4

13 years ago
<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. :-)
Flags: blocking2.18.1?
For the record, bug 43600 is the bug that broke this.
Flags: blocking2.20+
Flags: blocking2.18.1?
Flags: blocking2.18.1+
Keywords: regression
Target Milestone: --- → Bugzilla 2.18

*** This bug has been marked as a duplicate of 277277 ***
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Flags: blocking2.20+
Flags: blocking2.18.1+
Resolution: --- → DUPLICATE
Target Milestone: Bugzilla 2.18 → ---
(Assignee)

Comment 7

13 years ago
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.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
(Assignee)

Comment 8

13 years ago
Oh, arrgh. :-) They are separate bugs, but I realized that I can fix them both
with one patch. :-)
Depends on: 277277
Whiteboard: [blocker will fix]
Target Milestone: --- → Bugzilla 2.18
(Assignee)

Comment 9

13 years ago
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.
Blocks: 277277
Status: REOPENED → ASSIGNED
No longer depends on: 277277
Priority: -- → P1
Summary: checksetup fails to upgrade from Bugzilla 2.8 because there is no milestones.product field → checksetup fails to upgrade from Bugzilla 2.8
Whiteboard: [blocker will fix]
(Assignee)

Comment 10

13 years ago
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.
Attachment #178012 - Flags: review?(LpSolit)

Comment 11

13 years ago
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
Attachment #178012 - Flags: review?(LpSolit) → review+

Comment 12

13 years ago
mkanat, this patch does not apply cleanly to 2.18. Please backport this patch.
Flags: approval?
Flags: approval2.18?
(Assignee)

Comment 13

13 years ago
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.
Flags: blocking2.20+
Flags: blocking2.18.1+
Flags: approval?
Flags: approval2.18?
Whiteboard: patch awaiting review
(Assignee)

Updated

13 years ago
Attachment #178190 - Flags: review?(LpSolit)

Comment 14

13 years ago
Comment on attachment 178190 [details] [diff] [review]
Backport to 2.18

r=LpSolit
Attachment #178190 - Flags: review?(LpSolit) → review+

Updated

13 years ago
Flags: approval?
Flags: approval2.18?
Flags: approval?
Flags: approval2.18?
Flags: approval2.18+
Flags: approval+
Whiteboard: patch awaiting review → patch awaiting checkin
(Assignee)

Comment 15

13 years ago
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
Status: ASSIGNED → RESOLVED
Last Resolved: 13 years ago13 years ago
Keywords: relnote
Resolution: --- → FIXED
Whiteboard: patch awaiting checkin
(Assignee)

Updated

13 years ago
Keywords: relnote
You need to log in before you can comment on or make changes to this bug.