31

After making some changes in my models (eg. new field in a model and a new model) what is the best way of reflecting these changes to my populated database?

PS: I wanted to see many solutions in one place rated. Apparently more solutions are already listed here.

Community
  • 1
  • 1
hamdiakoguz
  • 15,795
  • 9
  • 33
  • 27

6 Answers6

24

Another technique is to use the dumpdata and loaddata arguments to manage.py, killing your database in-between:

  1. python manage.py dumpdata > dump.json
  2. With an external tool, drop any affected tables, or kill the whole db
  3. python manage.py loaddata dump.json

See manage.py docs for more.

shacker
  • 14,712
  • 8
  • 89
  • 89
  • `python manage.py sqlreset appname` prints the necessary SQL statements, but does not actually run them. – Vebjorn Ljosa Oct 17 '08 at 13:07
  • Nice solution. Thanks. In our case, on Django 14, we need to create an empty database before loading the fixtures. The DB can be created by syncdb, however, automatically created content types must be removed manually, before loading the dump. – Simon Steinberger May 03 '12 at 12:38
  • Look at the date of this answer. For sometime Django's own migration system is just as good or better as South. @Stian Jensen has the right answer. – Csaba Toth Nov 30 '16 at 16:40
18

I've asked a similar question here and got quite a few answers.

There are quite a lot of ways of doing it, like manually doing the dumping and reloading with SQL, using fixtures or using one of the "emerging" schema-evolution packages for Django:

Community
  • 1
  • 1
Farinha
  • 17,636
  • 21
  • 64
  • 80
3

Depends on the scope of the changes. If it's beyond an ALTER, you're doing major surgery. Make backups of model as well as database so you can go back.

My preference is to put your new (revised, corrected, expanded) model in as a NEW application. It won't have URL's or anything, just a model.

  1. Creating the new model as a new application. Create tests, just to be sure it works.
  2. syncdb to build this interim implementation of the new model.
  3. Write a little one-time utility to query your old model, and load your new model. You might want to try this in pure SQL. I prefer to write a simple query, build and save loop.
  4. After the new model is loaded, you can dump this to a JSON file.

Once you've pulled the data out of your old model, you can rebuild your DB in the preferred new format.

  1. Move the new model into your existing application.
  2. Drop the old versions of the application's tables.
  3. syncdb to build the new tables.
  4. Load the JSON file with the data.
S.Lott
  • 384,516
  • 81
  • 508
  • 779
3

Django now has its own built-in migrations, documented at:

https://docs.djangoproject.com/en/dev/topics/migrations/

Stian Jensen
  • 150
  • 2
  • 4
2

Look with manage.py sqlall what the parameters are for the new columns and manually add them in your database with Alter table statements. This way you don't have to redo your database; It requires some SQL knowledge though...

Take a look here (Scroll down to "Making Changes to a Database Schema")

fijter
  • 17,607
  • 2
  • 25
  • 28
0

Perform these steps in order may help you:

For more details,

clickhere: http://south.readthedocs.org/en/latest/

1) python manage.py schemamigration apps.appname --initial

Above step creates migration folder as default.

2) python manage.py migrate apps.appname --fake

generates a fake migration.

3) python manage.py schemamigration apps.appname --auto

Then you can add fields as you wish and perform the above command.

4) python manage.py migrate apps.appname

Then migrate the files to the database.

arulmr
  • 8,620
  • 9
  • 54
  • 69
Vijesh Venugopal
  • 1,621
  • 15
  • 26