On Thursday, October 9, 2014 12:01:45 AM UTC+3, Curtis Maloney wrote: > > Since I didn't know about the update feature in South... can you explain > how it would be different from migration squashing in 1.7? >
South's schemamigration --update has very little to do with migration squashing. Squashing can be used to simplify the migration history by squashing many migrations into one. This has two functions: - Having less files lying around - Optimizing the initialization of an empty database For a project that has already been deployed to a production server, the only advantage is having less migration files. The squashed migration will never be applied on the production server. For clarity, let's go through migration squashing first. Suppose you have the following migrations defined for myapp: myapp [X] 0001_initial [X] 0002_foo [X] 0003_bar [X] 0004_baz If you run ./manage.py squashmigrations myapp 0004, you get the following migration history: myapp [X] 0001_squashed_0004_baz (4 squashed migrations) Now, if someone starts *with an empty database*, it's enough that he runs this single optimized migration instead of the 4 original migrations. What the "makemigrations --update" command I'm proposing would do is this. Suppose you have these migrations defined for myapp: myapp [X] 0001_initial [X] 0002_foo [X] 0003_bar [X] 0004_baz Now you run "./manage.py makemigrations --update myapp". First, it rolls back the last migration: myapp [X] 0001_initial [X] 0002_foo [X] 0003_bar [ ] 0004_baz Then it removes the last migration altogether: myapp [X] 0001_initial [X] 0002_foo [X] 0003_bar Then it creates a new migration based on what has changed since 0003_bar: myapp [X] 0001_initial [X] 0002_foo [X] 0003_bar [ ] 0004_auto_20141009_0826 And that's it! So, instead of creating a new migration on top of 0004_baz, it wiped 0004_baz and created the new migration that replaces it. This is useful when developing a new feature. A single developer can test his changes by creating an unfinished migration and applying it, then writing some code that uses the changed database schema. If he finds that the new schema isn't good, he can change what is needed and update the migration. When the feature is ready, he'll commit the migration to version control and deploy it to production. In the production server, a single migration is run that contains *the final version* of his changes. If he hadn't used --update (which he currently can't do), he ends up creating many intermediate migrations. With South, updating a migration 5 times is not uncommon for me, so I with Django's built-in migrations I would end up with 5 migrations, when only one would have been enough. Futhermore, by unapplying and re-creating a migration I can make changes that would normally be harder to do. For example, changing a new model's name or changing a foreign key field to point to another table are not a problem. And changes like these really happen when developing a new feature. Petri -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/5fd91632-a4fa-46a0-8c30-3a9a81fd5918%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
