Django get syncdb sqlall statement to update after code changes

Question

Trying to see the SQL that syncdb would generate at the current moment in time.

After several searches the answer wasn't readily apparent -- I know you can use:

python manage.py syncdb --sqlall

returns:

Create the database tables for all apps in INSTALLED_APPS whose tables haven't already been created.

How can I output the changes that have happened for the entire database if the code has changed at all?

Is there a way to generate all of the SQL for all of the apps that need syncdb'ing at this time? Or need I just explicitly state each app? I'm not looking for all of the SQL for the entire site, just for the changes that would be implemented by a syncdb.

I've got several apps that need sql generated to describe the changes. I could explicitly list them, but is there a way for syncdb to figure this out for me ?

Answer 1

You can do

./manage.py sqlall <app_name>

to get the sql statements and initial data for the app.

If you want just the sql statements,

./manage.py sql <app_name>

Here is a mangement command that prints sqlall for ALL installed apps. Alternatively, you can write your own management command which gets all the installed apps, and calls the ./manage.py sql <app_name> for each.

Answer 2

The Django Extensions package has a number of custom management commands for django, one of these commands is sqldiff:

https://github.com/django-extensions/django-extensions/blob/master/docs/sqldiff.rst

First,

sudo pip install django-extensions

Next, add django-extensions to installed apps

INSTALLED_APPS = (
    ...
    'django_extensions',
    ...
)

Then, you can

python manage.py sqldiff -a

You'll be presented with a full list of differences, as well as a long list of ALTER TABLE statements that will ensure all fields are set properly (length, null, unsigned, etc)

Any tables that are not created will be listed, and you can then dump the SQL to create them using

python manage.py sqlall {app_label}

It's worth noting that for column name changes, sqldiff will attempt to simply drop renamed columns and create new ones in their place - So don't just copy the entire sqldiff and run it against production without inspecting.