What is the correct way to deal with DB migration while using South, Django and Git?

12
votes

Background :-

I am using Django 1.3. We are using South as the module for DB migration and Git SCM.

Problem:-

What is the correct way to deal with the migrations Folder that is formed?

The main problem is I make changes in the DB schema in the development machine, when I upload it to the production server I have to migrate the existing schema. While doing that there is always some issue with the migration files.

Should I just add the migrations folder to the gitignore ? or is there a better way to go about it ?

1
djangogitdjango-modelsdatabase-migrationdjango-south
What issue are you having with the migration files? I typically check these into git, and it works fine as long as you're careful to keep them in sequence (so no making new ones in parallel on different branches). – Danica
The issue is that if I migrate the schema on local machine and try to do the same on production machine it dint work once. Does this work ? i.e. do the same migration files work for the production server as well ? – Akamad007
Yes, they should, assuming you haven't made other changes to the DB. If you have a specific error message or something we can try to debug it, but "didn't work once" is hard to work from. :p – Danica
@AkashDeshpande, yes, they just need to be in the same state. That's the primary purpose of south (for me) - I can reset all my tables on development, but not so on production. When both systems are equal, run the initial migration (schemamigration --initial), commit it, and migrate myapp 0001 --fake on your production environment. From now on, every migration you create locally can be committed and safely applied on the server. – Yuji 'Tomita' Tomita

1 Answers

21
votes

You should add the migrations folder to your version control system and use the same files for production and development. You may run into some problems on your production system if you introduced your migrations not from the beginning and you have already existing tables.

Therefore you have to fake the first migration, which normally does the same thing as syncdb did when you created your database for the first time. So when trying to apply migrations for your app for the first time on the production machine, execute manage.py migrate app_name 0001 --fake. This lets South know, that the first migration has already been applied (which already happend with syncdb) and when you run migrate again, it would continue with the following migrations.