Hi Eduardo, I wrote some Fabric scripts for my own use to do a more complicated pg dump and restore. I had a production system to migrate from Mezzanine pre 1.x to 1.x. I used Fabric and Vagrant to iterate over write, build, test against a restore from a recent production dump. https://github.com/stephenmcd/mezzanine/blob/master/mezzanine/project_template/fabfile.py#L289-L302contains the `backup` and `restore` tasks. I used the `backup` task to build a `backup_production` task. The `create` task got modifications to `restore` the backup from production.
It was all quite complicated. I would have used fixtures, but Mezzanine had an issue with dumping FKs, although it might have been me. k On Fri, Mar 7, 2014 at 11:04 AM, Eduardo Rivas <[email protected]>wrote: > To he honest I don't know why the DATABASE setting is left in settings.py, > it definitely can be confusing. > > I believe the reason databases are not synced by the fabfile is because > that's not a very common (or advised) operation. Most of the time > developers want to keep production and development DBs completely > separated. However, I can think of a few situations where this could be > useful, and the general algorithm for a Fabric task would be: > > 1. Run pg_dump in your dev machine, output to file. > 2. Upload file to the project folder in the server. > 3. (Optional) Backup current production DB. > 4. Run pg_restore in the server from the latest uploaded SQL dump. > > -- > You received this message because you are subscribed to the Google Groups > "Mezzanine Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Mezzanine Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
