1
votes

I am using two enviorments for my django project, dev and production. mostly I am working on dev, when I change fields in my models I am using south to migrate to the new models.

What I dont understand is how can I now transfter it to my production database ? What I am doing is committing my code into SVN and updating on production, then try to migrate.

Should I commit my migration directory and files ? or should I not ? it seems that it allways fail when trying to migrate on my production machine.

EDIT : I have done additional tests. I have cleared my south histroy table and delete any migrations directories.

Now on my local enviorment I run : python manage.py convert_to_south app_name

everything seems to work perfectly. I have now add an additional field to my model and run : python manage.py schemamigration app_name --auto

The new field was migrate into my database as expected. Now, I commited my migrations folders with the .py files (contains 0001-initial and 0002 for my new field)

on my dev enviorment I updated my tree which includes the migrations files. I run python manage.py syncdb. the south_migrationhistory table was created but enpty.

now I run python manage.py schemamigration app_name --auto and got : "Nothing seems to have changed."

the south_migrationhistroy is still empty..... I have no clue what I am doing wrong here

1
The proper way would be to include all the migration files in svn, do a svn update on the production environment and run the migrations. Is it what you're doing ? If so, please give more details about what fails exactly.niconoe
If I am doing that it just say that "there is nothing to update"Nuno_147
Are you using two well-separated, different databases ? Normally South should detect what was the last migration applied and just run the new ones (thanks to the south_migrationhistory table) ...niconoe

1 Answers

0
votes

You Should commit your migration directory and files. When you do an svn update, south now knows what to do with your new migrations.

South looks up a database table called south_migrationhistory to see what migrations have already been applied, and based on that applies the new migrations specified in the migration folder. If you do not checkin the new migration files, it will always end up with "No new updates".