On new projects, we often go through an initial development period that ends up with a release, and then a subsequent maintenance period.
In the initial period we like using South because sometimes you just don't want to drop all the data you have in your dev DB. But, more importantly, we often run a reference implementation of projects for various people that do not have local environments of their own.
When we get to release time, we generally drop all the application tables and start over with fresh data. At this point, we'd like to toss all the migrations we have up to that point, and start over. Our new 001 migration should create the DB tables from the latest approve-for-release models. And then any subsequent migrations will be for bugs and features against the live system.
The way I just did it is this
1. Drop all the app tables. 2. Delete all the migrations for the app 3. Delete all records in the South History table
As long as you take care to do it on all deployments simultaneously, there shouldn't be any problem with this. Personally, I'd do:
rm -r appname/migrations/ ./manage.py reset south ./manage.py convert_to_south appname
(Notice that the "reset south" part clears migration records for ALL apps, so make sure you either run the other two lines for all apps or delete selectivey).
The convert_to_south call at the end makes a new migration and fake-applies it (since your database already has the corresponding tables). There's no need to drop all the app tables during the process.
> On new projects, we often go through an initial development period > that ends up with a release, and then a subsequent maintenance period.
> In the initial period we like using South because sometimes you just > don't want to drop all the data you have in your dev DB. But, more > importantly, we often run a reference implementation of projects for > various people that do not have local environments of their own.
> When we get to release time, we generally drop all the application > tables and start over with fresh data. At this point, we'd like to > toss all the migrations we have up to that point, and start over. Our > new 001 migration should create the DB tables from the latest > approve-for-release models. And then any subsequent migrations will > be for bugs and features against the live system.
> The way I just did it is this
> 1. Drop all the app tables. > 2. Delete all the migrations for the app > 3. Delete all records in the South History table
On Thursday, April 1, 2010 2:45:38 AM UTC+3, ristretto.rb wrote:
> Hello all,
> On new projects, we often go through an initial development period > that ends up with a release, and then a subsequent maintenance period.
> In the initial period we like using South because sometimes you just > don't want to drop all the data you have in your dev DB. But, more > importantly, we often run a reference implementation of projects for > various people that do not have local environments of their own.
> When we get to release time, we generally drop all the application > tables and start over with fresh data. At this point, we'd like to > toss all the migrations we have up to that point, and start over. Our > new 001 migration should create the DB tables from the latest > approve-for-release models. And then any subsequent migrations will > be for bugs and features against the live system.
> The way I just did it is this
> 1. Drop all the app tables. > 2. Delete all the migrations for the app > 3. Delete all records in the South History table
