How should the rollback work with the South?

Question

Color bothers me. Suppose we have a Django project with south transitions. Currently version of production project A , version in development B Now suppose version B installed in production:

• Set new code
• Run ./manage.py syncdb && ./manage.py migrate
• Reboot the web server and be happy.

The following assumption: version B does not work at all. This was done in development, but not in production, so it must be discarded. And here I have to miss something. I see two possibilities:

• Old code to reinstall. Now, southern reverse migration will be appropriate, however this is not possible, as the old code does not contain all the latest migrations needed to return.
• First, we roll back from the database changes, and then reinstall the old code. However, how do we know which migration is the latest for version A ? Since one project can easily count several dozens of applications, you will need to find out for each of them, which belongs to the old version, and then port each application separately, and then roll back the code and hope for the best.

In both cases, I do not have enough important information, either the transition code in the first case, or the relationship "migration <-> version" in the second. What am I missing here?

PS : Yes, I know that I can restore the database from a backup, this is what I actually do. I want to know how this migration theory of the entire database matches rollbacks.

Answer 1

OK I suppose you work with version control? At this point, it is very important to determine what constitutes “A” and “B”. If we swear / guess that this amorphous code of the code we are referring to is “A”, and this other vague thing that we all call “B”, this will not work.

If you are trying to reinstall "A" instead of "B", you have two options: 1) check and restore "A" from scratch (synchronization and migration) 2) flip "B" back to "A".

1) This probably will not work, because you cannot afford to kill data in the database in order to synchronize it from nothing 2) Involves migration. First, you should find the migration in "B", not in "A". In the south, all migrations for each application are numbered (0001, 0002, 0003, etc.). So let “B” be at 050 and “A” at 0031. While you select “B”, run python manage.py migrate appname 0031 This will python manage.py migrate appname 0031 all the changes to the database that you made for “B” . Then in your version control system you check for "A" ("A" is just a commit or tag or branch)

Unfortunately, you cannot roll back to "A" and then say "undo everything that you don't have." This would be an easier solution - but then you need a migration system to find out about your version control system, and it's a little hairy.

Answer 2

Not sure if this was an option in your case, but could you start back migration in production before moving the code back to version "A"? This way your db will go back to what kind of migration was there before your syncdb, and then you change your code back to version A and you will go back to where you started.