Closed Bug 307662 Opened 19 years ago Closed 19 years ago

checksetup.pl fails at some line (Unknown column 'grant_type' or similar error) when upgrading from 2.18 or below to 2.20

Categories

(Bugzilla :: Installation & Upgrading, defect, P1)

Product:
Bugzilla
Component:
Installation & Upgrading
Version:
2.20
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
Bugzilla 2.20

People

(Reporter: gunnar, Assigned: mkanat)

References

Details

Attachments

(1 file, 1 obsolete file)

v2
2.00 KB, patch
justdave
: review+
Details | Diff | Splinter Review
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6 checksetup fails when upgrading my 2.18.3 db to 2.20rc2+ (BUGZILLA-2_20-BRANCH) ...# ./checksetup.pl Checking perl modules ... Checking for AppConfig (v1.52) ok: found v1.56 Checking for CGI (v2.93) ok: found v3.04 Checking for Data::Dumper (any) ok: found v2.121 Checking for Date::Format (v2.21) ok: found v2.22 Checking for DBI (v1.38) ok: found v1.46 Checking for File::Spec (v0.84) ok: found v0.87 Checking for File::Temp (any) ok: found v0.14 Checking for Template (v2.08) ok: found v2.14 Checking for Text::Wrap (v2001.0131) ok: found v2001.09291 Checking for Mail::Mailer (v1.65) ok: found v1.67 Checking for Storable (any) ok: found v2.12 The following Perl modules are optional: Checking for GD (v1.20) ok: found v2.23 Checking for Chart::Base (v1.0) ok: found v2.3 Checking for XML::Parser (any) ok: found v2.34 Checking for GD::Graph (any) ok: found v1.43 Checking for GD::Text::Align (any) ok: found v1.18 Checking for PatchReader (v0.9.4) ok: found v0.9.5 Checking user setup ... Removing existing compiled templates ... Precompiling templates ... Checking for DBD::mysql (v2.9003) ok: found v2.9006 Checking for MySQL (v3.23.41) ok: found v4.1.11-Debian_4sarge1-log Checking for Net::LDAP (any) ok: found v0.32 Checking for GraphViz (any) ok: found Renaming indexes... Removing index 'creator_2' from the series table... Renaming index bug_id to attachments_bug_id_idx... Renaming index creation_ts to attachments_creation_ts_idx... Renaming index bug_id to bug_group_map_bug_id_idx... Renaming index group_id to bug_group_map_group_id_idx... Renaming index priority to bugs_priority_idx... Renaming index reporter to bugs_reporter_idx... Renaming index product_id to bugs_product_id_idx... Renaming index creation_ts to bugs_creation_ts_idx... Renaming index assigned_to to bugs_assigned_to_idx... Renaming index qa_contact to bugs_qa_contact_idx... Renaming index short_desc to bugs_short_desc_idx... Renaming index votes to bugs_votes_idx... Renaming index bug_severity to bugs_bug_severity_idx... Renaming index bug_status to bugs_bug_status_idx... Renaming index delta_ts to bugs_delta_ts_idx... Renaming index version to bugs_version_idx... Renaming index component_id to bugs_component_id_idx... Renaming index resolution to bugs_resolution_idx... Renaming index target_milestone to bugs_target_milestone_idx... Renaming index alias to bugs_alias_idx... Renaming index op_sys to bugs_op_sys_idx... Renaming index bug_id to bugs_activity_bug_id_idx... Renaming index bug_when to bugs_activity_bug_when_idx... Renaming index fieldid to bugs_activity_fieldid_idx... Renaming index category_id to category_group_map_category_id_idx... Renaming index bug_id to cc_bug_id_idx... Renaming index who to cc_who_idx... Renaming index product_id to components_product_id_idx... Renaming index name to components_name_idx... Renaming index blocked to dependencies_blocked_idx... Renaming index dependson to dependencies_dependson_idx... Renaming index sortkey to fielddefs_sortkey_idx... Renaming index name to fielddefs_name_idx... Renaming index type_id to flagexclusions_type_id_idx... Renaming index type_id to flaginclusions_type_id_idx... Renaming index bug_id to flags_bug_id_idx... Renaming index setter_id to flags_setter_id_idx... Renaming index requestee_id to flags_requestee_id_idx... Renaming index product_id to group_control_map_product_id_idx... Renaming index group_id to group_control_map_group_id_idx... Renaming index member_id to group_group_map_member_id_idx... Renaming index name to groups_name_idx... Renaming index name to keyworddefs_name_idx... Renaming index keywordid to keywords_keywordid_idx... Renaming index bug_id to keywords_bug_id_idx... Renaming index lastused to logincookies_lastused_idx... Renaming index bug_id to longdescs_bug_id_idx... Renaming index bug_when to longdescs_bug_when_idx... Renaming index who to longdescs_who_idx... Renaming index thetext to longdescs_thetext_idx... Renaming index product_id to milestones_product_id_idx... Renaming index userid to namedqueries_userid_idx... Renaming index name to products_name_idx... Renaming index login_name to profiles_login_name_idx... Renaming index userid to profiles_activity_userid_idx... Renaming index profiles_when to profiles_activity_profiles_when_idx... Renaming index fieldid to profiles_activity_fieldid_idx... Renaming index creator to series_creator_idx... Renaming index name to series_categories_name_idx... Renaming index series_id to series_data_series_id_idx... Renaming index userid to tokens_userid_idx... Renaming index user_id to user_group_map_user_id_idx... Renaming index bug_id to votes_bug_id_idx... Renaming index who to votes_who_idx... Renaming index watcher to watch_watcher_idx... Renaming index watched to watch_watched_idx... Updating column public in table series ... New: tinyint NOT NULL DEFAULT 0 Updating column isactive in table bug_status ... New: tinyint NOT NULL DEFAULT 1 Updating column isactive in table rep_platform ... New: tinyint NOT NULL DEFAULT 1 Updating column isactive in table resolution ... New: tinyint NOT NULL DEFAULT 1 Updating column isactive in table op_sys ... New: tinyint NOT NULL DEFAULT 1 Updating column isactive in table bug_severity ... New: tinyint NOT NULL DEFAULT 1 Updating column isactive in table priority ... New: tinyint NOT NULL DEFAULT 1 Updating column approved in table quips ... New: tinyint NOT NULL DEFAULT 1 Adding group editclassifications ... Adding group bz_canusewhines ... Adding group bz_canusewhineatothers ... DBD::mysql::db selectrow_array failed: Unknown column 'grant_type' in 'where clause' [for Statement "SELECT 1 FROM group_group_map WHERE member_id = ? AND grantor_id = ? AND grant_type = ?"] at ./checksetup.pl line 4067 Reproducible: Always Steps to Reproduce:
Assignee: database → installation
Component: Database → Installation & Upgrading
See also bug 299230. It seems your stored database schema got out of sync with your actual schema.
(In reply to comment #1) > See also bug 299230. > > It seems your stored database schema got out of sync with your actual schema. Mhm. Maybe. The installation was first done using 1.18rc1. I upgraded it recently to 1.18.3 and are now trying to fetch up with the 2.20 branch on my test machine.
(In reply to comment #1) > See also bug 299230. > > It seems your stored database schema got out of sync with your actual schema. Hi, I am seeing the exact same issue. Also when trying to move my data from 1.18.3 to 2.20. Do instructions exists somewhere on how to sync the schema back up?
We also saw this error upgrading from 2.18 to 2.20. In our case it turned out to be due to some of our test runs. We had used a copy of our database to run the initial test against but after running the first test we did not delete the bz_schema table so successive tests returned the error. By dropping the copy database and starting from a fresh copy we were ok.
(In reply to comment #2) > Mhm. Maybe. The installation was first done using 1.18rc1. I upgraded it > recently to 1.18.3 and are now trying to fetch up with the 2.20 branch on my > test machine. It's so weird. Although it failed on the production machine (running Windows), it worked ok on a fresh Linux box using the following steps: - checkout a fresh copy from CVS stable branch (2.20rc2+) - import database dump - copy data dir from the production system (at least file "versioncache" seems to be important) - run checksetup.pl
*** Bug 313138 has been marked as a duplicate of this bug. ***
Confirming the bug due to the dupes and problems reported on IRC. So many people having exactly the same problem when upgrading is not something we should ignore. mkanat, is there no way for checksetup.pl to compare (and fix) the real schema and the one stored in bz_schema before upgrading?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking2.20.1?
Version: unspecified → 2.20
Personally, I think it's bad practice to restore a database backup overtop of an existing database without dropping that database first (I'd never considered the thought of doing so, personally, I always drop and recreate a DB before restoring a backup). But, Joel thinks this should be easy to work around. <joel> It is only a problem if checksetup fails or if you roll back across the no_stored_schema point in time. <joel> That means we only need a mysql-sepcific check and it only needs to check one schema thing against the existance of bz-schema As long as there's an easy way for us to detect the situation, there's no reason we shouldn't do so and handle it.
Flags: blocking2.20.1? → blocking2.20.1+
Fair enough. I'll add a check in bz_setup_database in Bugzilla::DB::Mysql, to see if we're on 2.18 but already have a bz_schema table. But yes, I agree, people should stop doing silly things. I'll also warn them that they did something silly, perhaps.
Assignee: installation → mkanat
OS: Linux → All
Priority: -- → P1
Hardware: PC → All
Target Milestone: --- → Bugzilla 2.20
*** Bug 292794 has been marked as a duplicate of this bug. ***
Flags: blocking2.22+
*** Bug 316770 has been marked as a duplicate of this bug. ***
so many dupes... I don't think all these users have played with their installation before upgrading. Maybe is there really a bug in checksetup.pl.
Summary: checksetup fails in line 4067 when upgrading DB → checksetup.pl fails at line 4067 (Unknown column 'grant_type') when upgrading from 2.18.3 to 2.20
Status: NEW → ASSIGNED
Summary: checksetup.pl fails at line 4067 (Unknown column 'grant_type') when upgrading from 2.18.3 to 2.20 → checksetup.pl fails at some line (Unknown column 'grant_type' or similar error) when upgrading from 2.18 or below to 2.20
So basically what we do here is: If we have to rename the indexes (meaning that we're pre-Schema, or just at the very beginning of Schema before it was ever serialized) but bz_schema already exists, then we prevent the upgrade and tell them to go drop their DB and restore it. Joel, are you available to do the review? If you don't think you'll be able to get to it soon, feel free to redirect it to somebody else.
Attachment #205902 - Flags: review?(bugreport)
Attachment #205902 - Flags: review?(bugreport) → review?(LpSolit)
Comment on attachment 205902 [details] [diff] [review] Prevent upgrades when bz_schema exists pre-2.20 To be complete, we should tell them to drop it then create it, then restore the backup. restoring a mysqldump (usually) doesn't actually create the destination database, and will die miserably if it doesn't already exist.
Attachment #205902 - Flags: review?(LpSolit) → review-
Comment on attachment 205902 [details] [diff] [review] Prevent upgrades when bz_schema exists pre-2.20 How about this for the die text: You are upgrading from a version before 2.20, but the bz_schema table already exists. This means that you restored a mysqldump- based backup from an older version of Bugzilla overtop of an existing version 2.20 or newer database without first dropping the existing Bugzilla database to remove new tables that were added by version 2.20. Please drop and re-create an empty Bugzilla database and restore the backup again.
Hmmm... we should be nice and warn them about potential dataloss as well... "NOTE: This will cause dataloss if you've actually used your Bugzilla installation since said backup was restored."
Attached patch v2 — — Splinter Review
I didn't tell them to "re-create an empty database" in this patch, because I'm worried that would confuse some users who would think they would need to use checksetup to create an "empty" Bugzilla database. I just used general language that told them to "restore" their database.
Attachment #205902 - Attachment is obsolete: true
Attachment #206257 - Flags: review?(justdave)
Attachment #206257 - Flags: review?(justdave) → review+
Flags: approval2.20+
Flags: approval+
Checking in Bugzilla/DB/Mysql.pm; /cvsroot/mozilla/webtools/bugzilla/Bugzilla/DB/Mysql.pm,v <-- Mysql.pm new revision: 1.35; previous revision: 1.34 done 2.20: Checking in Bugzilla/DB/Mysql.pm; /cvsroot/mozilla/webtools/bugzilla/Bugzilla/DB/Mysql.pm,v <-- Mysql.pm new revision: 1.24.2.6; previous revision: 1.24.2.5 done
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: