Earlier quoted context omitted.
I wonder if there will be a tool to convert (migrate?) South migration data to Django's native format.
It has been stated by Andrew Godwin (author of South and the new native migrations) that there will be a clear path to switch from South to native migrations. And also for people who can't upgrade to 1.7 there should be South 2 with some of the new features backported from native migrations.
Django 1.7 alpha 1 released
11–20 of 23 posts
Re: Django 1.7 alpha 1 released
#12Wasn't the "New system check framework" already in 1.6? I remember seeing warnings about BooleanFields without defaults.
The ./manage.py validate command has been replaced with ./manage.py check in Django 1.7. The new system checks framework [1] is extensible, so third party apps will be able to add their own checks.
Re: Django 1.7 alpha 1 released
#13Re: Django 1.7 alpha 1 released
#14Is this because of the new migrations built-in module? [0]
Re: Django 1.7 alpha 1 released
#15It's great to see schema migrations move into Django core. South is great, but Django will be much better with schema migrations baked in, especially for newcomers. For anyone coming to Django from Rails, South seems anomalous. Outside of database migrations, Django is a very battery-included framework, so it's weird that until 1.7 data migrations were handled by third party tools (mostly South) and not mentioned at…
I wonder if there will be a tool to convert (migrate?) South migration data to Django's native format.
* Apply all South migrations to all database servers,
* Delete South migrations,
* Create new initial (create table) migrations for the current schema.
This makes sense, as migration code is supposed to be temporary. Migrations should exist in the codebase until the last database has them applied. Once all databases are up-to-date, it's better to delete them and "rebase" migrations to the current schema.
Old, fully applied migrations will still stay documented in the version control history, but they shouldn't be part of the master tree, much like obsolete code should be deleted instead of left commented out.
Re: Django 1.7 alpha 1 released
#16> Additionally, users of South (a popular third-party package for schema migrations) should note that South is not compatible with the 1.7 alpha. Is this because of the new migrations built-in module? [0] [0] https://docs.djangoproject.com/en/dev/topics/migrations/
Re: Django 1.7 alpha 1 released
#17> Applications can run code at startup, before Django does anything else, with the ready() method of their configuration. I have been waiting for something like this for a very long time. No more wondering where signals should go. [0] [0] https://docs.djangoproject.com/en/dev/ref/applications/#djan...
Re: Django 1.7 alpha 1 released
#18Earlier quoted context omitted.
I wonder if there will be a tool to convert (migrate?) South migration data to Django's native format.
The recommended upgrade path seems to be: * Apply all South migrations to all database servers, * Delete South migrations, * Create new initial (create table) migrations for the current schema. This makes sense, as migration code is supposed to be temporary. Migrations should exist in the codebase until the last database has them applied . Once all databases are up-to-date, it's better to delete them and "rebase" mig…
Re: Django 1.7 alpha 1 released
#19Wasn't the "New system check framework" already in 1.6? I remember seeing warnings about BooleanFields without defaults.
I wrote that BooleanFields without defaults patch! I'm glad that the warning has been seen by at least one person! The ./manage.py validate command has been replaced with ./manage.py check in Django 1.7. The new system checks framework [1] is extensible, so third party apps will be able to add their own checks. [1]: https://docs.djangoproject.com/en/dev/ref/checks/
Re: Django 1.7 alpha 1 released
#20It's great to see schema migrations move into Django core. South is great, but Django will be much better with schema migrations baked in, especially for newcomers. For anyone coming to Django from Rails, South seems anomalous. Outside of database migrations, Django is a very battery-included framework, so it's weird that until 1.7 data migrations were handled by third party tools (mostly South) and not mentioned at…
I wonder if there will be a tool to convert (migrate?) South migration data to Django's native format.