[zentrus]

Awesome that migrations are now in Django core. I do see some pitfalls regarding Historical Models though.

The problem is that application code usually changes over time. Consider a deployment that hasn't been migrated in a long time. When migrations are eventually run, the older migrations might assume application code behaved a certain way. This is why you should never use your regular application models in migrations. Both South and Django 1.7 migrations copy "shallow" versions of your models (no custom methods, save methods, etc), which helps to encourage developers to keep the migration isolated from application models that might change. The problem with Django 1.7 though is that these shallow versions retain any inheritance they had at the time the migration was written. So if that class goes away in the future, I presume the migration will break. Worse yet, if the base class behavior changes, the migration run later in time might behave differently than you intended.

For this reason, custom methods even from inheritance should not be saved in the historical model. Only the fields should be saved off from the base classes, and then merged into one class (remove any inherited classes). Any other app code needed for the migration should be directly copied into the migration itself.

[andrewingram]

I'm assuming that most of the pitfalls I wrote about a couple of years ago are still applicable today, with either South or Django's own migrations:

http://andrewingram.net/2012/dec/common-pitfalls-django-sout...

[zentrus]

That's a good set of pitfalls to watch out for. Mainly, I just find it odd that in Django 1.7, they are using frozen models to mitigate some of these problems, but don't remove or freeze the base classes, therefore leaving the same problem. I'm sure the migrations system will get better over time.