Is there a simple way to safely insert new migration to an old list of migrations?

14 views
Skip to first unread message

Lie Ryan

unread,
Nov 4, 2014, 6:24:45 AM11/4/14
to south...@googlegroups.com
One of my first applications to use South was written full of ignorance about how to do proper migrations and as a result, it had a serious flaw in its migration script. Namely is that I just have a simple autogenerated alter_column() where actually a 3-step schema-data-schema migration is needed, this is causing a migration failure when running the migration.

Or perhaps should I just fix up the data manually?

The application uses South 0.7.5.

Andrew Godwin

unread,
Nov 4, 2014, 12:36:44 PM11/4/14
to south...@googlegroups.com
Hi Lie,

What to do is very dependent on context. It's possible you could just modify the old migration in-place to fix it, faking the 3-step migration by adding a "db.commit()" line between the sections, though this may not give you the right models in the frozen ORM. Another possibility is to reset the entire migration history and start afresh, if you've already fixed the databases it's running on and it's not that widely distributed.

I'd encourage thinking about editing the old migration first; perhaps you can do the manual fix using a series of db.execute() statements right in there.

Andrew

--
You received this message because you are subscribed to the Google Groups "South Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to south-users...@googlegroups.com.
To post to this group, send email to south...@googlegroups.com.
Visit this group at http://groups.google.com/group/south-users.
For more options, visit https://groups.google.com/d/optout.

Shai Berger

unread,
Nov 4, 2014, 5:24:07 PM11/4/14
to south...@googlegroups.com
Hi Lie,

In addition to Andrew's wise advice, I'd like to point one detail:

Depending on the database backend you use, you may need to consider "dry runs"
-- these are done on MySql and Oracle in attempt to at least check the
migrations before starting to run them for real -- as on these databases,
schema changes cannot be done in a transaction which will be rolled back if
something fails along the way. In mixed schma+data migrations, the data
sections need to be put under "if not db.dry_run:".

HTH,
Shai.
Reply all
Reply to author
Forward
0 new messages