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?
-- C On 8 October 2014 17:33, Petri Lehtinen <pe...@digip.org> wrote: > Hi! > > The database migration system in Django 1.7 is really great and > seems to work very well. However, since I'm a long-time South > user, there's one feature that I'm missing: the possibility to > update an existing migration (the --update flag to South's > schemamigration command). > > I think it's an important feature because it allows you to make > massive changes to your models when developing a new feature, because > it rolls back the migration and rewrites it, effectively wiping > everything and starting from scratch for that migration. I can rename > tables, change foreign keys to normal fields and vice versa, > add/remove/rename M2M fields freely, etc., things that the migrations > don't normally handle very well automatically. When developing, > there's no need to retain data, so it's OK to roll back and lose all > the data in newly created tables, for example. It's also not very > efficient to leave all those intermediate steps in the migration > history to wait until squashmigrations is used some time in the > future. > > As a proof-of-concept, I created a shell script that does the > migration updating for a given app. It's not an universal > solution because it's tied to a certain directory hierarchy, > though. Here it is: > > #!/bin/sh > > project=PROJECTNAME > app=$1 > > cur=$(./manage.py migrate --list $app | tail -n 1 | grep '\[X\]' | sed 's/ > \[X\] //') > prev=$(./manage.py migrate --list $app | tail -n 2 | head -n 1 | grep > '\[X\]' | sed 's/ \[X\] //') > if [ -z "$cur" -o -z "$prev" ]; then > echo "Unable to find out current or previous migration. Have you run > all migrations?" > exit 1 > fi > echo "Rolling back to:" $prev > echo "Deleting and updating:" $cur > echo "Are you sure? [yN]" > read x > [ "$x" != "y" ] && exit 0 > ./manage.py migrate "$app" "$prev" > rm $project/$app/migrations/$cur.py > ./manage.py makemigrations "$app" > > What do you think? Could functionality like this be added to Django? > Are there problems I've missed with this approach? > > 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 django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > 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/20141008063316.GE32167%40p29 > . > For more options, visit https://groups.google.com/d/optout. > -- 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 django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. 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/CAG_XiSA19segRAgrz6942_PCuEe%3D-4G_eYe2C%2BD6X5vNc0adDQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
