Moving DB to new machine

10 views
Skip to first unread message

Greg

unread,
Apr 14, 2014, 8:49:18 AM4/14/14
to south...@googlegroups.com
Hi,

We have a customer that runs our app locally and is now moving to our shared server.  The shared server has multiple DBs and settings.py files.  Each DB on the shared server has migrations applied at the same time.  The DB moving over is at the same state as all of the other DBs but had differently named migrations applied.  How do I get this new DB to not try to apply all of the existing migrations sitting on the shared server?  Reading the docs I believe I just have to use --fake to get it to think all of the existing migrations have been applied.  But, I thought it best to confirm this.

Thanks.

Andrew Godwin

unread,
Apr 14, 2014, 10:19:28 AM4/14/14
to south...@googlegroups.com
Yes, --fake is the correct thing to use to modify a server's recorded migration data without actually unapplying or applying the migrations. Be careful, though, as it's easy to get your migration state screwed up this way.

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.

Greg

unread,
Apr 14, 2014, 11:19:08 AM4/14/14
to south...@googlegroups.com
Thank you.  I'm assuming you mean if I wanted to roll back a migration?  That should be fine as we never do.
Just to be consistent I'll probably empty the new DB's migrationhistory table before doing the fake.  Then their table will look like everyone else's.

Shai Berger

unread,
Apr 14, 2014, 5:16:06 PM4/14/14
to south...@googlegroups.com
On Monday 14 April 2014 18:19:08 Greg wrote:
> Thank you. I'm assuming you mean if I wanted to roll back a migration?
> That should be fine as we never do.
> Just to be consistent I'll probably empty the new DB's migrationhistory
> table before doing the fake. Then their table will look like everyone
> else's.
>

You'll need to do this anyway, otherwise you end up with ghost migrations.

Greg Miller

unread,
Apr 14, 2014, 10:14:24 PM4/14/14
to south...@googlegroups.com
Just to recap for future users...
We moved the DB, pg_restored it,
emptied south_migrationhistory
./manage.py migrate app --fake

All seems perfect.  We'll see next migration.  Thanks all.



--
You received this message because you are subscribed to a topic in the Google Groups "South Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/south-users/JlFZ7M4apdQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to south-users...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages