Re: Mechanics of the EmailValidator.domain_allowlist rename.

OK, thanks both — perhaps we're worrying too much. > For example, the get_query_set -> get_queryset rename... I'd managed to suppress that memory. 😀 C. On Thursday, 18 June 2020 19:05:54 UTC+2, Adam Johnson wrote: > > I also lean towards #1. > > I doubt many third party packages use the argum

Re: Mechanics of the EmailValidator.domain_allowlist rename.

I also lean towards #1. I doubt many third party packages use the argument since it seems quite site specific. I scrolled through 5 random-ish pages of github code search for "domain_whitelist" in python files and found nothing that looked like a django related usage. On Thu, 18 Jun 2020 at 16:42

Re: Mechanics of the EmailValidator.domain_allowlist rename.

Hi I have survived a few changes in Django over the last >10 years, and this change is absolutely not comparable to any of the problematic ones. For example, the get_query_set -> get_queryset rename was hard because it was unclear how to properly support subclassing querysets. The on_delete addi

Mechanics of the EmailValidator.domain_allowlist rename.

Hi All, We merged the docs changes remove whitelisted &co last week. https://github.com/django/django/pull/13031 There's a PR now ready to adjust EmailValidator to use domain_allowlist. https://github.com/django/django/pull/13079/ This is all fine *except* it will require editing any historic

Re: Defaulting to use BigAutoField in models

Email got sent too fast I meant > The warning should warn that the value will default to 'django.db.models.BigAutoField' in a future version of Django. Regarding third party apps a solution could be to allow a per-app config option or encourage them to explicitly choose which primary key they

Re: Defaulting to use BigAutoField in models

+1 from me as well but I don't think we should add any logic to the migration framework to handle the transition. I think the release plan should be something along the following Phase 1: - New projects are generated with MODEL_DEFAULT_PK = 'django.db.models.BigAutoField' - A system check or wa

Re: Defaulting to use BigAutoField in models

This would make the change only affect existing installs of third party apps. I think documentation on using RunSQL() in a migration (in a project app) could be warranted. On Thu, 18 Jun 2020 at 14:50, Caio Ariede wrote: > What about third party apps? > > It would be great to migrate every AutoF

Re: Defaulting to use BigAutoField in models

What about third party apps? It would be great to migrate every AutoField to BigAutoField without the need to specify them manually. -- Caio > On 18 Jun 2020, at 09:40, Adam Johnson wrote: > > Would we be able to provide instructions on how to migrate from SIGNED INT to > UNSIGNED BIG INT

Re: Defaulting to use BigAutoField in models

> > Would we be able to provide instructions on how to migrate from SIGNED INT > to UNSIGNED BIG INT? Perhaps a management command that outputs SQL like > sqlmigrate? > It would only be needed to add this to the model: id = BigAutoField() Then migrations would pick it up, because the field is no

Re: Defaulting to use BigAutoField in models

> On 17 Jun 2020, at 16:56, Adam Johnson wrote: > > I think special casing the migrations framework is an avenue to explore, so I > created this today and to my surprise it seems to work quite well: > https://github.com/orf/django/commit/0a335f208cee1376c25eff55c6f866de122c7839 >