role_permission required to upgrade from D6 to D7
gordon - July 20, 2009 - 02:43
| Project: | Drupal |
| Version: | 7.x-dev |
| Component: | update system |
| Category: | bug report |
| Priority: | normal |
| Assigned: | gordon |
| Status: | closed |
Description
To run an upgrade the role_permission table needs to exist or an error is caused which stops the upgrade pages from getting to the next selection page.
I have added to the update_fix_d7_requirements() to create the role_permission table so that it can get past the check.
This still gets updated during the upgrade, but the table exists.
| Attachment | Size | Status | Test result | Operations |
|---|---|---|---|---|
| 0002-role_permission-required-to-upgrade.patch | 2.75 KB | Idle | Failed: Failed to apply patch. | View details |

#1
Strangely, I am able to reproduce this issue, but only occasionally. Most of the time I've tried upgrading, it works fine. But on a few occasions (with no discernible pattern whatsoever), I have seen this error.
In particular, the error message occurs during system_update_7007() and consists of:
An error occurred.Path: http://localhost/drupal/update.php?id=2&op=do
Message: PDOException: SQLSTATE[42S01]: Base table or view already exists: 1050 Table 'role_permission' already exists: CREATE TABLE {role_permission} (
`rid` INT unsigned NOT NULL,
`permission` VARCHAR(64) NOT NULL DEFAULT '',
PRIMARY KEY (rid, permission),
INDEX permission (permission)
) ENGINE = InnoDB DEFAULT CHARACTER SET UTF8; Array
(
)
in db_create_table() (line 2096 of /home/droth/web/drupal/includes/database/database.inc).
It would be ideal if we could figure out what's causing this issue, before trying to work around it - but I have no ideas at the moment, and the fact that it's only an intermittent problem is troubling :)
#2
The last submitted patch failed testing.
#3
Updated version of the patch
#4
I've had this when a contrib (7) module has been installed, which calls user_access(), such as devel does in hook_boot().
#5
Opps forgot to change the status
#6
Yes this explains it, and why it is going to be a problem in a future.
#7
The last submitted patch failed testing.
#8
Fix up the conflicts in the patch
#9
The last submitted patch failed testing.
#10
HEAD is broken.
#11
The last submitted patch failed testing.
#12
Re-rolled.
#13
+++ includes/update.inc 24 Oct 2009 01:31:35 -0000@@ -128,10 +128,15 @@ function update_fix_d7_requirements() {
- // add empty columns for now.
+ // Add empty columns for now.
Ahaha. I am a slacker for not catching that in the last patch. :)
+++ includes/update.inc 24 Oct 2009 01:31:35 -0000@@ -128,10 +128,15 @@ function update_fix_d7_requirements() {
+ variable_set('update_d7_requirements', TRUE);
Why are you setting this here when it's already being set further down?
+++ modules/system/system.install 24 Oct 2009 01:31:37 -0000@@ -2012,7 +2012,9 @@ function system_update_7007() {
+ if (!db_table_exists('role_permission')) {
+ db_create_table('role_permission', $schema['role_permission']);
+ }
Why do we need this hunk anymore if we're taking care of this in update_fix_d7_requirements() now?
This review is powered by Dreditor.
#14
Removed bogus variable_set(), removed table creation from 7007()
#15
+++ includes/update.inc 24 Oct 2009 01:35:47 -0000@@ -128,10 +128,14 @@ function update_fix_d7_requirements() {
+ $schema['role_permission'] = drupal_get_schema_unprocessed('user', 'role_permission');
+++ modules/system/system.install 24 Oct 2009 01:35:48 -0000
@@ -1992,28 +1992,6 @@ function system_update_7006() {
- $schema['role_permission'] = array(
- 'fields' => array(
- 'rid' => array(
- 'type' => 'int',
- 'unsigned' => TRUE,
- 'not null' => TRUE,
- ),
- 'permission' => array(
- 'type' => 'varchar',
- 'length' => 64,
- 'not null' => TRUE,
- 'default' => '',
- ),
- ),
- 'primary key' => array('rid', 'permission'),
- 'indexes' => array(
- 'permission' => array('permission'),
- ),
- );
-
- db_create_table('role_permission', $schema['role_permission']);
-
Oops. It just occurred to me from reading this hunk that we need to add that table definition to update_fix_d7_requirements(). drupal_get_schema_unprocessed() is going to get the /current/ schema of the table, which may or may not be the same in 7.0 as it is in 7.24.
See also http://drupal.org/node/150220
I'm on crack. Are you, too?
#16
Include full schema definition in update_fix_d7_requirements().
#17
Awesome, think we got it now. :)
Committed to HEAD!
#18
Automatically closed -- issue fixed for 2 weeks with no activity.