3 ms·

Everything stems from the fact South attempts to freeze your model definitions in time for each migration. While this works, often you need more than just the m

Everything stems from the fact South attempts to freeze your model definitions in time for each migration. While this works, often you need more than just the model definition (what effectively generates the DDL), but the surrounding codebase / Django magic as well (methods, model managers, etc.). Another pain point with South is that you run your migrations after pushing a new release. That makes for hard zero-downtime updates, because your codebase and the database are out of sync for a while before you can run `django-admin.py migrate`. After having used South, I feel the best approach still is to write your own SQL migrations by hand and run it against your database pre-deploy, never destroy data (erase/update columns/tables), and then make sure your codebase handles the new/absent columns/tables transparently. This way you can revert a broken release just pushing the previous version.

bmelton 14y ago
I've always had luck just running the migrations before hand -- the only real caveat there is that you need to do a two-step migration process if you're removing fields. If all your changes are additions, and your app is managed by supervisord, it's fairly trivial to pull the code updates, run the migrations, then bounce your supervisor instance. Like I said though, if you're deleting, the process is to stage out the deletes into a separate migration so that your codebase is using new or added/replacement columns before you remove tables or you're kind of screwed. Also bear in mind that this knowledge is somewhat dated as all my recent Django ORM experience is based on Oracle (ugh) which I haven't gotten South to work with.
- hcarvalhoalves 14y ago
  > I've always had luck just running the migrations before hand -- the only real caveat there is that you need to do a two-step migration process if you're removing fields. If all your changes are additions, and your app is managed by supervisord, it's fairly trivial to pull the code updates, run the migrations, then bounce your supervisor instance. The problem is that some configurations need workers to restart every X requests to avoid memory leaks, and that makes the deployment process completely non-deterministic if you're pushing new code and expecting workers to still serve the old one. There are troubles with dynamic imports too, which happen on large codebases.
  - bmelton 14y ago
    That's a good point that I didn't consider. I'm using Gunicorn and now that you mention it, I dunno how much is or isn't dynamic, but my process is dynamic so it takes seconds to happen and may or may not be throwing errors. I've never noticed any errors deploying as described, but that doesn't necessarily mean anything in light of this information.

bmelton 14y ago

I've always had luck just running the migrations before hand -- the only real caveat there is that you need to do a two-step migration process if you're removing fields. If all your changes are additions, and your app is managed by supervisord, it's fairly trivial to pull the code updates, run the migrations, then bounce your supervisor instance. Like I said though, if you're deleting, the process is to stage out the deletes into a separate migration so that your codebase is using new or added/replacement columns before you remove tables or you're kind of screwed. Also bear in mind that this knowledge is somewhat dated as all my recent Django ORM experience is based on Oracle (ugh) which I haven't gotten South to work with.

hcarvalhoalves 14y ago
> I've always had luck just running the migrations before hand -- the only real caveat there is that you need to do a two-step migration process if you're removing fields. If all your changes are additions, and your app is managed by supervisord, it's fairly trivial to pull the code updates, run the migrations, then bounce your supervisor instance. The problem is that some configurations need workers to restart every X requests to avoid memory leaks, and that makes the deployment process completely non-deterministic if you're pushing new code and expecting workers to still serve the old one. There are troubles with dynamic imports too, which happen on large codebases.
- bmelton 14y ago
  That's a good point that I didn't consider. I'm using Gunicorn and now that you mention it, I dunno how much is or isn't dynamic, but my process is dynamic so it takes seconds to happen and may or may not be throwing errors. I've never noticed any errors deploying as described, but that doesn't necessarily mean anything in light of this information.