4 ms·

Andrew is providing some additions in South 1.0 to ease the transition a bit, probably not to the degree he had hoped earlier in the process: http://south.read

by huxley 12y ago

Andrew is providing some additions in South 1.0 to ease the transition a bit, probably not to the degree he had hoped earlier in the process: http://south.readthedocs.org/en/latest/releasenotes/1.0.html http://south.readthedocs.org/en/latest/releasenotes/1.0.html "As part of providing a migration path for authors of third-party apps and libraries for Django, South will now first look for migrations in the south_migrations directory, and then fall back to the migrations directory if this is not found. This is intended to alleviate the namespace clash between South and Django migrations; prior to this, both were looking for a directory called migrations, and so it was impossible to ship a third-party app with support for both South and Django 1.7. The recommendation is that you move your South migrations into the south_migrations directory (existing users will not notice the change if they upgrade South first), and then start a new set of Django 1.7 migrations in a migrations directory (the default)."

zentrus 12y ago
Thank you. This is closer to a much better upgrade path. The official documentation is really not a good way to have non-technical customers move from South to Django 1.7. With the new version of South, you could package both old South (perhaps some of them not yet run) as well as the new migrations. It could be better though. With this approach, they would still have to: 1) ./manage.py migrate 2) pip uninstall south 3) ./manage.py migrate Better yet would be to have either South or Django 1.7 migrations check for the other's existence and run both sets of migrations and not force South to be removed. This would make it a truly seamless transition for the system administrator.
radiac 12y ago
How good are Django 1.7 migrations at detecting things which have already happened? In particular, can you safely maintain South migrations alongside Django ones, or do you have to force users to switch? The problem I envisage is that when you add 1.7 support to your app, you move your old migrations into south_migrations and start a clean migrations dir, as the instructions say - but what happens when your next release makes a database change? If you want to support all active versions (1.4, 1.6 and 1.7) you'd have to add a South migration and a 1.7 migration to support both groups of users - but then they no longer have a clean upgrade path from South to 1.7. From reading the docs, it looks like 1.7 schema migrations may detect the changes have already been made and skip over them, but what will happen when you have data migrations too? Does 1.7 figure out which operation you're up to by comparing your migrations to the database state, and starting migrations once the two match? What if at some point you return to an older set of model fields - does it match on the earliest or the latest? I plan on avoiding the issue as long as possible: get my apps as feature complete as possible under South (with instructions for 1.7+ users for creating their own migrations), then bump the version when I switch from South to Django migrations. I'll then try to backport bugfixes to the South version (as long as they don't change the db) until support for Django 1.4 and 1.6 are dropped.

by huxley 12y ago

zentrus 12y ago

Thank you. This is closer to a much better upgrade path. The official documentation is really not a good way to have non-technical customers move from South to Django 1.7. With the new version of South, you could package both old South (perhaps some of them not yet run) as well as the new migrations. It could be better though. With this approach, they would still have to: 1) ./manage.py migrate 2) pip uninstall south 3) ./manage.py migrate Better yet would be to have either South or Django 1.7 migrations check for the other's existence and run both sets of migrations and not force South to be removed. This would make it a truly seamless transition for the system administrator.

radiac 12y ago

How good are Django 1.7 migrations at detecting things which have already happened? In particular, can you safely maintain South migrations alongside Django ones, or do you have to force users to switch? The problem I envisage is that when you add 1.7 support to your app, you move your old migrations into south_migrations and start a clean migrations dir, as the instructions say - but what happens when your next release makes a database change? If you want to support all active versions (1.4, 1.6 and 1.7) you'd have to add a South migration and a 1.7 migration to support both groups of users - but then they no longer have a clean upgrade path from South to 1.7. From reading the docs, it looks like 1.7 schema migrations may detect the changes have already been made and skip over them, but what will happen when you have data migrations too? Does 1.7 figure out which operation you're up to by comparing your migrations to the database state, and starting migrations once the two match? What if at some point you return to an older set of model fields - does it match on the earliest or the latest? I plan on avoiding the issue as long as possible: get my apps as feature complete as possible under South (with instructions for 1.7+ users for creating their own migrations), then bump the version when I switch from South to Django migrations. I'll then try to backport bugfixes to the South version (as long as they don't change the db) until support for Django 1.4 and 1.6 are dropped.