migrate does not store default values in the database

[Peter Coles]

I'm trying out the migrations in Django 1.7 and I was surprised when my migrations did not set default values in the database. Can someone share the motivation for this functionality? (more details below)

This was surprising given the documentation I read:

1. the release notes for 1.7 suggest using `null=True` for new database columns, but only because of the potential performance impact during a site update (which seems odd, since the migrations don't set default values anyways…)
2. the example of a migration file clearly shows a default value of `0` for the Author.rating field, even though it turns out the default isn't used

Running `python manage.py sqlmigrate appname migrationnumber` for an example like the Author.rating addition in the docs would look something like this:

BEGIN;
ALTER TABLE "author" ADD COLUMN "rating" integer NOT NULL DEFAULT 0;
ALTER TABLE "author" ALTER COLUMN "rating" DROP DEFAULT;

COMMIT;

However, looking in the source code, I can see: "(Django usually does not use in-database defaults)".

I find it quite problematic for production site updates, since my updates generally look like:

1. generate migrations
2. run migrations on prod db, while old webserver code is still running
3. after migrations, update webserver

I cannot afford to have breaking problems between steps 2 & 3 if I want to add a new db column that is not null and has a default value.

Does anyone here know the motivation for the existing no-defaults-in-the-db functionality? I'd like to know, since I'm putting together a backend derived from 'django.db.backends.postgresql_psycopg2' that is exactly the same, except for setting default values in the db, and I'd like to know what concerns there might be for a backend like this?

[Jon Dufresne]

Before migrations were built-in there was a bug report about this:
<https://code.djangoproject.com/ticket/470>. It might be of some help.
It was closed as wontfix. Not sure if the addition of migrations has
changed anyone's mind.

Cheers,
Jon

[Peter Coles]

Should I copy this question over to "django-dev" (do they accept posts from non-internal devs)? I've seen people complain in the past about reopening or commenting on closed tickets.

[Carl Meyer]

Hi Peter,

On 10/24/2014 05:26 PM, Peter Coles wrote:
> Should I copy this question over to "django-dev" (do they accept posts
> from non-internal devs)? I've seen people complain in the past about
> reopening or commenting on closed tickets.

Django core dev here. Yes, the django-developers mailing list is open to
anyone, and your question is on-topic for it (since it's a question
about Django's design and possible improvements/changes to it).

And you are right that bringing the question to the mailing list is the
right approach, not reopening a ticket that has been closed wontfix
(multiple times).

I would suggest that you carefully read through the full history of
https://code.djangoproject.com/ticket/470 and make sure you understand
why it has been closed wontfix, so that you can make an argument for how
you'd address those problems (e.g. callable default values) in your
proposed change. That will increase your chances of starting a
productive discussion on the topic.

Carl

[Carl Meyer]

For bonus points, you might also search the archives of
django-developers to see if there have been past mailing-list threads on
the topic as well.

Carl