migrate (with South) the DB schema around, which of cours necessitates
changing domain and test code.
A common problem I run into, though, is that I also need to migrate
the data in my fixtures. It is possible to create a new DB, sync it
to a given migration point, load the fixture, run the remaining
migrations, and dump a new fixture, then drop the extra db. But it
seems like a very awkward dance given how often I have the problem.
Is there already a solution to this? It seems to me that South could
manage some book keeping to maintain what fixtures are at which
migration level, and a new south command could manage the migration of
fixtures.
./manage migrate --fixtures [all other options staying the same]
I imagine this would read/write some bookmark files to each affected
app's ./fixtures/ directory. If the bookmark file didn't exist, the
0001 schema would be assumed. Otherwise it'd be something along the
lines of:
fixture_file.name.south, and contents would roughly mirror
south_migrationhistory, perhaps in JSON format.
Thoughts?
--
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to django-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
No comments:
Post a Comment