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.
On Friday, October 24, 2014 7:05:41 PM UTC-4, Jon Dufresne wrote: > > On Fri, Oct 24, 2014 at 3:24 PM, Peter Coles <peter....@gmail.com > <javascript:>> wrote: > > 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: > > > > 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…) > > 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: > > > > generate migrations > > run migrations on prod db, while old webserver code is still running > > 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? > > 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 > -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/d92a3a01-b12e-4b65-90ee-ec272aedab5f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
