Upgrading patchwork

Jeremy Kerr jk at ozlabs.org
Fri Dec 9 01:30:46 EST 2011

Hi Ralf,

>  o incomplete and missing documentation
>  o I'm using MySQL but the migration scripts were written for another db,
>    probably Postgres.

Yeah, unfortunately it has do be done by hand at present, and I only
have the time to test on my own setup, which uses Postgres. The current
migration strategy is "catch me on IRC and I'm happy to walk you through

In future, I'm planning to automate these, by adding a version number to
the database, plus a script that is able to bring you from version N to
version N+x.

>  o After all the migration scripts confirmation links were not working.

>    The culprit was the type column of the patchwork_emailconfirmation
>    table.  This is how it was looking:
> 	CREATE TABLE `patchwork_emailconfirmation` (
> 	  `id` int(11) NOT NULL AUTO_INCREMENT,
> 	  `user_id` int(11) DEFAULT NULL,
> 	  `email` varchar(200) NOT NULL,
> 	  `key` char(40) NOT NULL,
> 	  `date` datetime NOT NULL,
> 	  `active` tinyint(1) NOT NULL,
> 	  `type` int(11) DEFAULT NULL,
> 	  PRIMARY KEY (`id`),
> 	  KEY `patchwork_userpersonconfirmation_user_id` (`user_id`)
>    But on a fresh  installation I got:
> 	CREATE TABLE `patchwork_emailconfirmation` (
> 	  `id` int(11) NOT NULL AUTO_INCREMENT,
> 	  `type` varchar(20) NOT NULL,
> 	  `email` varchar(200) NOT NULL,
> 	  `user_id` int(11) DEFAULT NULL,
> 	  `key` char(40) NOT NULL,
> 	  `date` datetime NOT NULL,
> 	  `active` tinyint(1) NOT NULL,
> 	  PRIMARY KEY (`id`),
> 	  KEY `patchwork_emailconfirmation_fbfc09f1` (`user_id`)
>    It seems there is no migration script to perform the upgrade of the
>    type column.  I've resolved that manually.

OK, thanks for the info. I have *no* idea how you ended up with a
int(11) type column though; that column was added in 56e2243f3, as a
varchar(20). As far as I can see, there have been no other fields called
'type' in the past.

>    In the 2nd definition of the patchwork_userpersonconfirmation_user_id
>    key there is a strange hexadecimal suffix.  Not sure what that means ...

That's just django limiting the maximum name length. Since it's on an
index, it won't be referenced anywhere else.

>    Also the CHARSET=latin1 makes me feel a little uneasy because these days
>    we mostly live in a UTF-8 world.

Yep, your fields should be in utf-8; the migration shouldn't have
altered this. However, I believe that this is only the default charset,
and django is explicit about which charset it is using when connecting
to the database, so this shouldn't cause a problem. You may want to
change the default, just to be sure though.

>  o lib/sql/migration/006-maintainer-project-attributes.sql creates a
>    table patchwork_projectmaintainer which does not exist in a fresh
>    install.  Should this upgrade script just be ignored / deleted?

Good catch, looks like that one snuck in when I was doing some
development. I've now removed the script, feel free to ignore it.



More information about the Patchwork mailing list