On Thursday 30 October 2014 23:00:18 Andrew Godwin wrote: > > If this does happen, I'd probably want some way to declare what defaults to > keep. (South actually used to have this with a keep_default option on the > add_column method but it was kind of unmaintained) > IIRC, in the few South releases between 0.7.3 and 0.8.2 we killed the functionality, and only kept accepting the parameters to avoid breakage of old migrations.
Defaults-in-the-DB may be OK on Postgres (I'm not fluent enough in it to tell), but they lead to very odd problems on Oracle, e.g, requiring special, non- obvious actions in order to make backups possible. I'm really not sure about the other backends; and I think the behavior in this respect should be uniform across backends (and welcoming to 3rd-party backends as well). Peter, you said you're "interested in getting database migrations to support setting database-level default values", but you haven't said why; unless there's a convincing use-case, I'm going to be -1 on this (per the new rules, this is no longer a veto, but still). I would be much less opposed to a specific default-setting operation in migrations -- that is, allowing users to explicitly set db-level defaults if they really want to; my main concern is with the automatic translation of a model-level default to a database-level one. Shai. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/201410311548.15207.shai%40platonix.com. For more options, visit https://groups.google.com/d/optout.
