1.95 KB
Newer Older
1 2 3 4 5 6 7 8 9 10
Upgrading and Downgrading

django-sshkey is equipped with [South][1] migrations.  This makes changes to
the database schema in upgrades or downgrades a simple process.  Migrations
will only be present on minor version changes.

To use South migrations, you must have the south app in your project's

The following table maps django-sshkey version to migration labels:
12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53

    Version   App Name        Label   Notes
    1.0.x     sshkey          0001    Migrations were not present in 1.0.x
    1.1.x     sshkey          0002
    2.0.x     django_sshkey   0001    See Upgrading from 1.1.x to 2.x below

To upgrade, install the new version of django-sshkey and then migrate your
project to its corresponding label from the table above using the following

    python migrate <app_name> <label>

To downgrade, perform the migration down to the label of the desired version
before installing the older django-sshkey.

Upgrading from 1.1.x to 2.x

django-sshkey 2.x renames the sshkey app to django_sshkey.  However, the
database table names are not changed.

To upgrade, all references to the sshkey module must be changed to
django_sshkey.  This includes all instances of "import sshkey" or
"from sshkey import ..." and all references to sshkey in url patterns, views,
or templates, as well as updating INSTALLED_APPS in

Once you have made those changes you will need to fake the initial migration
for django_sshkey:

    python migrate --fake django_sshkey 0001_initial

This completes the upgrade process.  The only thing that remains is the two
existing migration records in the south_migrationhistory table from the now
nonexistent sshkey app.  These records do not cause any problems, but they can
be removed at your discrection using the following SQL statement on your

    DELETE FROM south_migrationhistory WHERE app_name="sshkey";