South - migrating django application from sqlite to mysql

Question

I have a django application and until now I used sqLite as database backend. Now when it's quite close to production I thought of moving it all to mySQL which will be used on the box.

I reconfigured my settings to a mysql database and run

manage.py syncdb --migrate

it started creating tables and all but failed in the first (out of 40) migration with an old error (can't insert blob without key length and all that).

I first thought of manually fixing the migration files but quickly realized there is too much manual work.

So I thought ok I'll run manage.py migrate core 0040 (the last migration and that will do the trick) but it still attempts to run the initial one as well:

File "D:\~Sasha\Portman\core\migrations\0001_initial.py", line 23, in forwards
  ('name', self.gf('django.db.models.fields.TextField')(unique=True)),
... error message

Is there a way to migrate my models somehow without manually fixing the initial migration file and all the other magic?

Answer 1

First, you can't pick and choose migrations to run. migrate core 0040 means run all migrations up to 0040. In other words, it wouldn't run 0041, but it would run 0001-0040.

Now, it's side-stepping your question a bit, but if you have not moved this project to production yet, you don't actually need all those migrations. Assuming they're all schemamigrations you can rollback to zero with:

python manage.py migrate core zero

Then, delete them all (including 0001_initial.py) and simply run again:

python manage.py schemamigration --initial core

To regenerate the initial migration. It will base it off the current state of your models, negating the need for 40 migrations.

It's always a good idea to compress your migrations like this before you move new code to production. Since this is the first launch, you can remove them all and start from scratch, but in future iterations, if you generate 5 migrations during the course of development, before you commit, rollback to before the first of those, then delete those 5 and then generate a new schemamigration. The result is just one migration with all the changes of those 5. Then, you can commit that and migrate in production.

It may not solve your problem completely here, but it will definitely make things simpler to debug.