Closed (duplicate)
Project:
Mail Editor
Version:
6.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
24 Feb 2009 at 19:13 UTC
Updated:
28 Feb 2009 at 13:34 UTC
This should get you started. I thought I'd finish it out, but then it occurred to me that renaming mailkey to id might not be the right thing to do since mailkey is in the new registry table. Since I don't have any data in my table yet, I don't know what data if any needs to move between the tables in an upgrade.
function mail_edit_update_6000() {
$ret = array();
db_drop_primary_key($ret, 'mail_edit');
db_add_field($ret, 'mail_edit', 'language', array(
'type' => 'varchar',
'length' => '10',
'not null' => TRUE,
'description' => t(''),
)
);
db_change_field($ret, 'mail_edit', 'mailkey', 'id', array(
'type' => 'varchar',
'length' => '255',
'not null' => TRUE,
'description' => t(''),
)
);
db_add_index($ret, 'mail_edit', '`unique entry`', array('`id`', '`language`'));
db_add_index($ret, 'mail_edit', '`id`', array('`id`'));
db_add_index($ret, 'mail_edit', '`language`', array('`language`'));
db_create_table($ret, 'mail_edit_registry', array(
'description' => t(''),
'fields' => array(
'id' => array(
'type' => 'varchar',
'length' => '255',
'not null' => TRUE,
'description' => t(''),
),
'module' => array(
'type' => 'varchar',
'length' => '255',
'not null' => TRUE,
'description' => t(''),
),
'mailkey' => array(
'type' => 'varchar',
'length' => '255',
'not null' => TRUE,
'description' => t(''),
),
'description' => array(
'type' => 'varchar',
'length' => '255',
'not null' => TRUE,
'description' => t(''),
),
),
'primary key' => array('`id`')
)
);
return $ret;
}
Comments
Comment #1
salvisI'm confused. What makes you think we need another upgrade path?
Please see #318324: Upgrade strategy D5 -> D6 ?...
Comment #2
deekayen commentedThe project node says so. I apparently also have an old checkout of 6--1 from CVS, which didn't have it in there.
Comment #3
salvisIndeed, the D5 version does not have enough data to allow automatic migration to the D6 version. The id's are now prepended with the name of the module that defines them, so it would be pure luck if this would just work. Also, you'll need to make up corresponding records for the {mail_edit_registry} table, too.
The idea behind the upgrade path that I implemented was to a) allow installing the D6 version over a pre-existing D5 version at all (without resorting to database surgery) by moving the {mail_edit} table to the side to make room for a new one, and b) to save the pieces so that client modules can pick them up and put them into the new database structure based on their own knowledge of how the pieces are used. This works fine with Subscriptions, but I don't have any experience with other modules, so if you can contribute a complementary view on how D5 data could be migrated to D6, then please do so.
@litwol: Why is
still on the project page?