So we have a lot of Django-based code where we'd like the user to be able to download a (subset of) the Django database as a "config file", then upload that "config file" to some number of other machines (or the original one), potentially long after the database has been migrated. I've got the skeleton of that working, I record all of the current migrations in the data-file, I play the migrations forward to that point, then attempt to insert the records, then continue migrating. That almost works, but inserting the stored records fails, as the standard "loaddata" command is trying to use Django's live models, rather than South's migration models.

There's a snippet for getting a particular South data migration to use the South models, but for this I want any release of the product to be able to store/restore, not just particular releases. It seems it should be possible to do a horrific hack where I temporarily set settings.SOUTH_MIGRATION_MODULES for all supported apps to point to a package where I have a migration that imports the current migration for the app and produces a data-migration that's just that migration with the forwards/backwards methods overridden and then uses the code in the snippet to force use of that while doing the loaddata... and then I suppose I need to clean out the DB of that migration... which all seems to be getting a bit Byzantine.

So, anyone got a clean implementation, or should I wend my Byzantine way?

Update: don't have time to look any further today, but after tracing through the South machinery it looks like I could just create the Migration sub-class, patch the model importing, and run .forwards() directly... have to try that tomorrow.