On Wed, 2007-08-29 at 21:12 +0800, Russell Keith-Magee wrote:
> There are 2 options for workarounds:
> 1) use SQL ALTER statements rather than resetting the table. This
> requires writing manual SQL statements to modify the existing tables
> 2) Drop the entire database and start again from scratch
>
> 2 is the easier option, but isn't viable if you have data that cannot
> be lost. However, if you are in the initial phases of development, it
> should be all you need.
Cool, thanks for the speedy and clear response
Yes i am in the initial development phase at the moment and so option 2)
is much more attractive.
I was hoping something similar would be tenable for the production phase
as well... just dumping the data and then re-loading after recreating
the database, with some possible data munging if the schema has changed
in an incompatible way. For my project the downtime for the
dump/rebuild/load cycle should be short. Also I'm imagining scripts to
modify yaml will be more straightforward & flexible than doing any
manipulation with SQL.
Does anybody think this is a reasonable solution or am i missing
something?
A bash script along the lines of this is what I think would work...
--
DATA_APPS="auth foo bar"
mkdir -p upgrades
TMPDIR=`mktemp -d -p upgrades`
for app in $DATA_APPS; do
./manage.py dumpdata --format=yaml $app > $TMPDIR/$app.yaml
done
sudo su - postgres -c "dropdb mydb"
sudo su - postgres -c "createdb mydb"
./manage.py syncdb --noinput
for app in $DATA_APPS; do
./manage.py loaddata --format=yaml $TMPDIR/$app.yaml
done
--
cheers,
Graham
--~--~---------~--~----~------------~-------~--~----~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
