On 07/28/2015 11:55 PM, Loïc Bistuer wrote: > +1 on db defaults as well, I've actually started experimenting on > this last week. It's a bit tricky because migrations do use db > defaults in some operations (and drop them once they are done) so we > have to ensure that the new feature doesn't interfere with them. > > However I don't think we should create them by default, instead I > propose the introduction of a db_default kwarg, which should be > either a constant, or an expression (e.g. > db_default=contrib.postgres.functions.TransactionNow).
+1 to this approach. We should not try to conflate Python-level defaults and db-level defaults into a single kwarg (that way lies madness), nor implicitly introduce db-level defaults for existing models where Django never used them historically. A separate `db_default` kwarg is clear, explicit, and matches precedent from SqlAlchemy. Carl -- 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/55B8F1EF.2030501%40oddbird.net. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: OpenPGP digital signature
