Search code examples
migrationdjango-south

Database migration with south: how to deal with added fields


I am developing a django project which lives on Heroku. As the project evolves, a problem occurs when new fields are added to a data model: during makemigration, south will ask something like the following:

...
?  1. Quit now, and add a default to the field in models.py
?  2. Specify a one-off value to use for existing columns now
...

It isn't easy get around this (I tried to choose the second answer but south wouldn't accept whatever I entered).

Questions:

1) Some suggest that null=True should be added to the new field to avoid such a problem. However, the field should not be null. I end up making a workaround: makemigration with null=True, delete null=True, perform makemigration again, and then push to Heroku.

Is this the right way of doing it?

2) Using south migration causes another problem. Because we are a development team, every member may perform migration in his/her environment. When it comes to pushing to GitHub, the 00*_* files in each app's migration folder may conflict each other. How to solve it? Currently, we just ignore the 00*_* files since our project is not in production yet. What if it is in production later?

3) I only ran makemigrations and migrate and never used schemamigration. The system runs fine though. Do I have to run schemamigration?


Solution

  • 1) When you get an error message like that, basically it's asking for a one-off default. What exactly you should put in there when selecting option 2 depends entirely on your situation, but it must be a valid Python expression. For example:

    • If I have an IntegerField I want to add, I could enter 0
    • For a CharField, I could use "my string" (Note the quotes must be there)
    • For a ForeignKey, I would specify the primary key of the object I want to use.

    2) This is the hardest part about South. Conflicting migrations have to be merged carefully, and manually. The Django 1.7 migrations that replace South are much better at doing this automatically, so if at all possible, upgrade to 1.7+.

    3) I believe makemigrations is an alias for schemamigration. Get used to makemigrations because it's what the command is called in Django 1.7+.