Re: default values on database level
Closing the loop here -- Tim just reopened https://code.djangoproject.com/ticket/470. This feature would also be useful for achieving zero-downtime migrations, as discussed in https://code.djangoproject.com/ticket/29266. Sounds like the design has mostly been agreed -- would a PR be accepted that just implements the simple `db_default` field without attempting PostgreSQL RETURNING or database functions (CURRENT_TIMESTAMP), and just provides static defaults? Cheers, Paul On Monday, April 4, 2016 at 2:08:39 AM UTC-7, Shai Berger wrote: > > Hi everybody, > > Waking this up again because, going over some older stuff, I found a > ticket > asking for this feature: > > https://code.djangoproject.com/ticket/470 > > It was closed wontfix, but if anybody likes to put a 3-digit-numbered > Django > bug under their belt, it's there. The discussion in this thread would > indicate > that it should be re-opened. > > 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 https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/0918d753-2d98-4731-8180-922cc8e1d1d9%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Setting defaults in the DB to support zero-downtime migrations
It can be quite fiddly to support zero-downtime DB migrations in Django. For example see https://dev.mysql.com/doc/refman/5.7/en/data-type-defaults.html for tricks in Postgres; I'll refer to MySQL herein. In general the sequence is to first upgrade the DB schema to the new version, while keeping the old version of the application running. This works if the DB fields have a `DEFAULT NULL`, or if strict mode is not enabled; in either case omitted fields are defaulted to NULL or the implicit default, respectively (under MySQL). However it seems that manual SQL must be written in order to support adding fields that aren't nullable; since Django's ORM drops the DB-level default when the field is not nullable, there's a window after the schema migration, but before the application code has been upgraded, where the old-version code could try to write a None to the DB, while the new-version DB schema doesn't support it. For example, a NullBooleanField(default=None) produces this SQL: `bool_field` tinyint(1) DEFAULT NULL, Whereas a BooleanField(default=False) (or NullBooleanField with a default) produces: `bool_field` tinyint(1), This is the same for the other field types I've investigated; Django explicitly removes the default from the DB when migrating from a Nullable Field to a non-Nullable one. In MySQL using non-strict mode, this would often go unnoticed (since MySQL coerces NULL to the implicit default in that case), but under strict mode is recommended, that option is not available (per https://dev.mysql.com/doc/refman/5.7/en/data-type-defaults.html). Achieving zero-downtime migrations would be much easier if the default value was set in the DB; is there a reason that Django does not do this? Even if this was an optional flag which only worked for literal values (i.e. not functions), it would seem to be a very useful feature. (e.g. `Field(set_default_in_db=True)`). Indeed it seems to me that (based on the paucity of articles/documentation around hitless DB migrations) currently most Django users are likely incurring brief outages every time they perform a migration (perhaps without realizing it), whereas if DB-level defaults were the default behaviour, writing hitless DB migrations would require a lot less thought. I'm sure there's been discussion of this before, so apologies in advance for being unable to locate that thread; I'd be interested in any thoughts around this. Cheers, Paul -- 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 https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/3581b394-2d16-485b-a836-8e28c1983470%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Proposal: local timezone-aware datetime fields in the admin site
Thanks Aymeric, A bit of digging gives: MacOS Chrome: "America/Los_Angeles" MacOS Firefox: "America/Los_Angeles" MacOS Safari: "America/Los_Angeles" Windows Edge: ""America/Los_Angeles" Do you know what OS/browser combination you were referring to with "Windows (which, I'm afraid, has its own time zone name)"? I haven't got around to testing locales, I'll report back once I do that. On Wednesday, October 3, 2018 at 11:10:26 PM UTC-7, Aymeric Augustin wrote: > > Hello Paul, > > Yes, if that works, it would be great. > > The API you're pointing to returns a timezone name. This is better than an > offset because it avoids being off by one hour when editing dates or times > on the other side of the DST change. > > You need to check what it does on Windows (which, I'm afraid, has its own > time zone name) and whether it's locale-dependent (that would be a mess). > > If this API reliably returns a timezone name that pytz understands, then > you should be able to achieve your goal in the Widget for datetime fields > and to preserve backwards-compatibility. > > Best regards, > > -- > Aymeric. > > > > On 3 Oct 2018, at 23:04, Paul Tiplady > > wrote: > > Timezone handling in the Django admin is quite confusing for users when > the users are in multiple timezones, because everything in the admin site > operates in the server's time. > > Assuming USE_TZ=True, TIME_ZONE='UTC', USE_I18N, USE_L10N, when viewing a > datetime field, users see the UTC time, with a note below saying "Note: You > are 7 hours behind server time". This is better than nothing, but with a > modern browser I believe it's possible to improve the situation. > > The ideal behaviour (I believe) would be localizing the timezones in the > browser to the user's own time zone, and submitting back to the app using > TZ-aware timestamp strings. It's possible to pull the TZ unambiguously from > a modern browser: > https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/DateTimeFormat/resolvedOptions#Browser_compatibility#Description > . > > ``` > Intl.DateTimeFormat().resolvedOptions().timeZone > ``` > > Would this approach be acceptable? It seems that we'd want to default to > the normal behaviour, and perhaps have this as config on the AdminSite > object (since we want a way to enable this globally for sites that wish to > use this feature). > > (Originally raised here: https://code.djangoproject.com/ticket/29822, > posting for discussion) > > -- > 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-develop...@googlegroups.com . > To post to this group, send email to django-d...@googlegroups.com > . > Visit this group at https://groups.google.com/group/django-developers. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/79896a0e-1338-4267-89bd-9904fca4f0d2%40googlegroups.com > > <https://groups.google.com/d/msgid/django-developers/79896a0e-1338-4267-89bd-9904fca4f0d2%40googlegroups.com?utm_medium=email_source=footer> > . > 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 https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/b668a840-4884-4dc7-908f-32e2a2b493b9%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Proposal: local timezone-aware datetime fields in the admin site
Timezone handling in the Django admin is quite confusing for users when the users are in multiple timezones, because everything in the admin site operates in the server's time. Assuming USE_TZ=True, TIME_ZONE='UTC', USE_I18N, USE_L10N, when viewing a datetime field, users see the UTC time, with a note below saying "Note: You are 7 hours behind server time". This is better than nothing, but with a modern browser I believe it's possible to improve the situation. The ideal behaviour (I believe) would be localizing the timezones in the browser to the user's own time zone, and submitting back to the app using TZ-aware timestamp strings. It's possible to pull the TZ unambiguously from a modern browser: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/DateTimeFormat/resolvedOptions#Browser_compatibility#Description . ``` Intl.DateTimeFormat().resolvedOptions().timeZone ``` Would this approach be acceptable? It seems that we'd want to default to the normal behaviour, and perhaps have this as config on the AdminSite object (since we want a way to enable this globally for sites that wish to use this feature). (Originally raised here: https://code.djangoproject.com/ticket/29822, posting for discussion) -- 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 https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/79896a0e-1338-4267-89bd-9904fca4f0d2%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
