Re: sys.exit(1) from makemigrations if no changes found

On Thursday 30 October 2014 15:22:01 Dan Poirier wrote: > Wouldn't enabling this by default cause a problem for any automated > deploys? The discussion is about the makemigrations command, not migrate. The OP wants to use it to find automatically if there are model changes not covered by migrati

Re: Setting database default values in migrations (postgres)

Well, it's not a problem for anything done through Django as it'll always do the default correctly; the existing migrations don't do it right either, for sure, but they'll either error on application or work and everything's fine. Leaving the defaults in there would mean that non-Django code tryin

Re: Setting database default values in migrations (postgres)

Interesting scenario. However, the same example seems entirely broken in the existing django migrations with `null=False` and a default too, right? If so, maybe our current lens is a bit too myopic, and the UNIQUE scenario is a separate problem where model updates on existing tables can sometime

Re: Setting database default values in migrations (postgres)

Well, the one big problem with callable defaults is people who use them for UNIQUE fields (e.g. they're using uuid as the value or something). These migrations will apply fine to empty tables - as there's no data to cause non-unique issues with - but your solution would leave an entirely invalid de

Re: Setting database default values in migrations (postgres)

Thanks for the quick response! I just tried datetimefields with `datetime.datetime.now` and `timezone.now` as defaults (and another one with null=True, just to see). They just evaluated the callables and set those as static default values, e.g., the code generated was this: BEGIN; ALTER TABLE "

Re: sys.exit(1) from makemigrations if no changes found

Wouldn't enabling this by default cause a problem for any automated deploys? Ours typically run the migrate command on every deploy, just in case there are new migrations, and any command that returns a non-0 exit status is going to look like a deploy failure. Having the behavior change with a ne

Re: Websockets... again

Luis, I think what Alex and Aymeric are saying is that "websockets" (I use quotes to show that I mean not only the material outlined in RFC 6455 but also the general process of handling bytes-on-the-wire when 'pushing' data to the 'client') are ideally not part of the problem that Django (and WSGI

Re: Setting database default values in migrations (postgres)

Hi Peter, The main reason this hasn't been done in the past was that Django has never made use of database defaults, mostly for the reason described in that thread - that Django is sufficiently expressive with its defaults (you can pass in any callable) that we can't represent them in the database

Setting database default values in migrations (postgres)

Hey all, I'm interested in getting database migrations to support setting database-level default values. I've heard talk of this being a hotly contested issue in the past, but I haven't been able to find the actual conversations, so far this