Changes between Version 2 and Version 3 of Tutorial3

Timestamp:

04/18/09 10:45:11 (4 years ago)

Author:

andrew

Comment:

--

Tutorial3

@@ -105 +105 @@
 }}}
 
-This is bad practice. TBC....
+This is bad practice. Instead, as I described above, you should be making three migrations. Starting with your models.py file in the original state, we should:
+
+ * Add the new `first_name` and `last_name` fields.
+ * Run `./manage.py startmigration southdemo add_firstlast_name --auto` - this should make a `0003_add_firstlast_name.py` migration.
+ * Run `./manage.py startmigration southdemo migrate_names` - this should create `0004_migrate_names.py` (which will just be a blank template, since we gave startmigration no options)
+ * Remove the `name` field from models.py.
+ * Run `./manage.py startmigration southdemo remove_name --auto` - this will make `0005_remove_name.py`.
+
+This process can be extended to any kind of migration - do any additions of fields, then create a blank migration in the middle to add your data migration to, then do another removal of fields. This way, in the middle migration, you have access to both the fields you are moving data from and the fields you're moving it to.
+
+You can have a look at the 0003 and 0005 migrations if you wish, but they're reasonably standard schema migrations. We're interested in `0004_migrate_names.py` - open it up, and you should see this:
+
+{{{
+#!python
+from south.db import db
+from django.db import models
+from southdemo.models import *
+
+class Migration:
+    
+    def forwards(self, orm):
+        "Write your forwards migration here"
+    
+    
+    def backwards(self, orm):
+        "Write your backwards migration here"
+    
+    
+    models = {
+        ... cut for clarity ...
+    }
+    
+    complete_apps = ['southdemo']
+}}}
+
+When you run `./manage.py startmigration` with only an app name and a migration name, South will create a skeleton template of a migration for you to fill in - it's much more useful than doing that part yourself.
+
+Here, we're interested in data migrations, and so we'll be using the ORM. One thing you should note is that the ORM will '''not work during a dry run''' - if you're using MySQL, all migrations are dry-run before each application, and if you're on another database, you should code to make sure your migrations are portable. You have two ways of making ORM code not run during a dry run:
+
+ * Wrapping the ORM code in an `if not db.dry_run:` block
+ * Adding the `no_dry_run = True` statement to the Migration class
+
+We'll do the latter, since our entire migration will be using the ORM, and in general you should be making migrations this way anyway. Adding it to the class, we get this:
+
+{{{
+#!python
+from south.db import db
+from django.db import models
+from southdemo.models import *
+
+class Migration:
+    
+    no_dry_run = True
+
+    def forwards(self, orm):
+        "Write your forwards migration here"
+    ...
+}}}
+
+Now, we can start writing our migration. You use the fake ORM just like the normal ORM, but prefixing all models with `orm.`. Thus, our loop to copy the names across might look something like this:
+
+TBC