Hi Loic, Agree with having a db_default kwarg.
I am not using multiple databases so no experiance with db routers. So how would should we handle routing between different databases when the db_default value is not compatible with that backend? for example Model.save(using='mysql_db') should we than use the Field.default to generate the default value (which is not how it works today, that the default is computed at instance creation). I would prefer in such a case to rely on the database to handle the situation by omitting that field from the columns list, so mysql for example would set a non nullable varchar column to an empty string, where with other databases it would cause an IntegrityError exception. and that db_default and default kwargs cannot be used togethor. On Jul 29, 2015 1:55 AM, "Loïc Bistuer" <loic.bist...@gmail.com> wrote: > Hi Aron, > > +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). > > Cheers, > Loïc > > > On Jul 29, 2015, at 12:04, Podrigal, Aron <ar...@guaranteedplus.com> > wrote: > > > > I would like to propose making Fields.default to rely on the database > generated defaults where possible. This could be implemented by having > some constants like fields.CURRENT_TIMESTAMP, etc. The tricky part here > is to detect database backend specific capabilities and have a python > equivalent fallback. > > > > Any thoughts? > > > > > > -- > > 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/CANJp-yi5%2Bu%3DW8PdUXtcot%2BO8%3Df35dVLbStwVArJhU7gDnaNXoA%40mail.gmail.com > . > > For more options, visit https://groups.google.com/d/optout. > > -- > 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/125BCDAB-728B-4BAA-A8AB-38BA0842B709%40gmail.com > . > For more options, visit https://groups.google.com/d/optout. > -- 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/CANJp-yjsEthdkNQUaUKW3DfgyeigtjyZMYQoGteX%2BQ4MM4uPAw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
