Saturday, April 25, 2015

Re: Migrations During Development

Version: GnuPG v1

On 04/25/2015 11:28 AM, Timothy W. Cook wrote:
> if you don't store migrations, then you have to generate them on each
> production update, right? if so, wouldn't they count as untested
> code? how about manually tweaked, or data migrations?
> ​That will certainly be true once you start using a staging or
> production server.
> But before they they are just a kind left over creative ideas. :-) Not
> really useful for anything in the future, AFAICS.

If you only have one deployment (your local machine), you can erase all
your migrations and "start over" anytime with a new initial migration,
with no problems.

Once you have additional deployments (either other developers' machines,
or staging or production deployments), you shouldn't remove or change
any migrations that have been pushed to those other deployments.

You can use the "squash" feature [1] to squash a set of historical
migrations down to a single migration. This requires a phased
deployment, where you first push out a version including both the new
squashed migration and all the old replaced migrations, and then later
(once you are confident all deployments are up to date) you can safely
remove the old replaced migrations.

It's also true that if you have a series of new migrations locally that
haven't yet been pushed to any other deployment, you can delete and
replace them with a single migration before pushing.

It's very much like VCS commits: it's ok to edit your local history, but
you have to be a lot more careful with history that you've already
shared with others.


You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
To post to this group, send email to
Visit this group at
To view this discussion on the web visit
For more options, visit

No comments:

Post a Comment