restore a dropped table

230 views
Skip to first unread message

Jeff Bauer

unread,
Feb 12, 2010, 12:42:34 AM2/12/10
to south...@googlegroups.com
In the process of creating some sample test data ...

I serialized a table into json format, then dropped
the table. Normally when I'd do this, I'll run
syncdb and django will recreate the table. Then I'll
import a modified json file.

However, running ./manage.py migrate doesn't appear
to create the missing table. Is this correct behavior?

My workaround was to rename the migrations subdirectory,
run manage.py syncdb, then restore the migrations
directory.

--
Jeff Bauer
Rubicon, Inc.

Andrew Godwin

unread,
Feb 12, 2010, 3:55:04 AM2/12/10
to south...@googlegroups.com
Well, it depends how you dropped the table - did you log in and do it by
hand (bad!) or reverse the migration (good!)?

If you modify the database by hand, South won't notice - its only way of
keeping track of what version the database is is the
south_migrationhistory table, so if you fiddle behind its back, it's
your responsibility to fix it.

If you did in fact reverse the migration (eg ./manage.py migrate appname
zero), then this is a south bug, and I'd appreciate more details (basic
model outline, south version, django version)

Andrew

Jeff Bauer

unread,
Feb 12, 2010, 7:48:37 AM2/12/10
to south...@googlegroups.com
Andrew,

I did not reverse the migration; I dropped the table
manually.

It's admittedly an edge case, but I might argue that
South could notice a missing relation and re-create it.
Anyway, I'm not complaining, just pushing the buttons
and learning how South works.

Jeff Bauer
Rubicon, Inc.

Andrew Godwin

unread,
Feb 12, 2010, 7:51:30 AM2/12/10
to south...@googlegroups.com
It could do, but that's a major departure from how South works. It
doesn't deal with models, and it doesn't really know what's supposed to
be there; at its core, it's just an engine which runs a series of SQL
statements, and then records having done so.

The rest of it (like autodetection of changes) is entirely separate from
the database. There's an argument that some part of South could detect
that your database didn't match your current migration's frozen state,
but that requires a whole bunch of code, and to then execute statements
about models (rather than just 'a migration') is yet again a different
way of doing things.

I'm not saying it's a bad workflow, it's just not the way South is
designed to work right now!

Andrew

Reply all
Reply to author
Forward
0 new messages