Adrian, > I'd personally like to see better support for safe / N-1 compatible migrations within Django itself, currently if you do CD / blue-green tower / etc. deployments you need to be very careful about the migration operations that you introduce version-to-version, although I'm not sure what that would look like.
There's a little project that we use at $WORK to do just that[0]. I'm not sure its inclusion in core is even proposable at this time as is still has received very little feedback from external users but the gist of the tool is that it introduces a notion of phases to migrations (pre and post-deployment) and augments the `makemigrations` command so it splits operations that require multiple phases in multiple migrations and adds a `--pre-deploy` flag to the `migrate` command to only run migrations meant to be run prior to a deployment. I don't want to hijack the this thread to discuss it in details but feel free to try it out and reach out personally if you'd like more details. We've used it internally to deploy changes using ArgoCD to Kubernetes clusters internally and I was planing on presenting the tool in the near future at a Django event once we get more feedback about it. [0] https://github.com/charettes/django-syzygy Cheers, Simon Le mardi 29 novembre 2022 à 04:41:49 UTC-5, ator...@redhat.com a écrit : > I'd personally like to see better support for safe / N-1 compatible > migrations within Django itself, currently if you do CD / blue-green tower > / etc. deployments you need to be very careful about the migration > operations that you introduce version-to-version, although I'm not sure > what that would look like. > > +1 to OIDC, CORS and DB defaults > > If nothing else, this thread has at least made me aware of some > interesting tickets :-) > > Adrian > > On Tuesday, November 29, 2022 at 5:35:40 AM UTC+1 Adam Johnson wrote: > >> I am not sure the db level defaults PR is suitable for a GSoC project at >> this point - it’s pretty well developed. I think it could do with some >> review and testing form those who are interested. >> >> On Mon, 28 Nov 2022 at 17:10, 'st...@jigsawtech.co.uk' via Django >> developers (Contributions to Django itself) <django-d...@googlegroups.com> >> wrote: >> >>> +1 from me on DB defaults (constraints too). I've worked on many systems >>> where Django isn't the only place putting records into DBs and having DB >>> level defaults and constraints fixes a lot of common issues with that. >>> Currently I create an empty migrations to then add them in manually when >>> required >>> >>> >>> +1 from me on moving models between apps, though I know it can be a >>> pain. Contacting and freelancing means you come across a lot of projects >>> where models are seeming in the wrong app or where you want to consolidate >>> apps and being able to move them cleaning would be a wonderful addition >>> On Monday, 28 November 2022 at 16:59:48 UTC John Whitlock wrote: >>> >>>> I'd like to see database-level defaults supported in models and >>>> migrations: >>>> >>>> https://code.djangoproject.com/ticket/470 >>>> >>>> There's currently a PR open, which replaces an earlier 2020 PR >>>> >>>> https://github.com/django/django/pull/16092 >>>> >>>> It would be a large benefit to those of us practicing continuous >>>> deployment. It is also tricky enough that it would benefit from a >>>> full-time >>>> effort to implement and refactor. >>>> >>>> - John >>>> >>>> On Tue, Nov 15, 2022 at 3:11 AM Carlton Gibson <carlton...@gmail.com> >>>> wrote: >>>> >>>>> Hi all. >>>>> >>>>> Google Summer of Code (GSoC) for 2023 has just been announced. >>>>> >>>>> https://opensource.googleblog.com/2022/11/get-ready-for-google-summer-of-code-2023.html >>>>> >>>>> Django has participated many times, and it's been a real boon. Recent >>>>> successes include: >>>>> >>>>> * The django-stubs mypy plugin. >>>>> * The cross-db JSON field. >>>>> * The Redis cache backend. >>>>> * Per model-class (field instance) custom lookups >>>>> * Setup of the django-asv benchmarking project. >>>>> * ... >>>>> >>>>> Application deadline for Orgs is February 7. I'll begin working on it >>>>> after the New Year. >>>>> >>>>> Main bit is an ideas list for projects. The GSoC guide has a Writing a >>>>> Good Ideas List >>>>> section. >>>>> >>>>> > Projects should take ~175 hours or ~350 hours for GSoC contributors >>>>> to complete. >>>>> >>>>> i.e. "short" or "long" projects. >>>>> >>>>> https://google.github.io/gsocguides/mentor/defining-a-project-ideas-list >>>>> >>>>> I'm writing here *to solicit input on project ideas*. >>>>> >>>>> I put "Technical Board?" in the subject because we're short a list of >>>>> project >>>>> ideas for the technical direction of Django going forward, and maybe >>>>> thinking >>>>> in terms of GSoC could be a way of bootstrapping that. The "?" is >>>>> because that's not >>>>> meant to exclude other input. >>>>> >>>>> Here's last year's list for reference: >>>>> https://code.djangoproject.com/wiki/SummerOfCode2022 >>>>> >>>>> - Some of those were done: benchmarking (but that could be built on) >>>>> and per-instance >>>>> field lookups. >>>>> >>>>> - Rate-limiting is a no-go I think: we couldn't come to any decent >>>>> agreement on scope, >>>>> so it's better to live as a third-party package. >>>>> >>>>> - I've tried to include folks from the wider ecosystem in previous >>>>> years. Two years ago >>>>> we had both Wagtail and django-stubs projects. Wagtail then (last >>>>> year) >>>>> applied in their own right, to great success. I'd like to offer that >>>>> help >>>>> again to e.g. Jazzband or other established projects, assuming >>>>> maintainers >>>>> feel they have the capacity to mentor. (It's a minor increment to my >>>>> effort >>>>> for a good return I think.) >>>>> >>>>> >>>>> No urgency but, can I ask you to put your grey cells into action? 🙂 >>>>> >>>>> >>>>> Thanks. >>>>> >>>>> Kind Regards, >>>>> >>>>> Carlton >>>>> >>>>> -- >>>>> >>>> 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 view this discussion on the web visit >>>>> https://groups.google.com/d/msgid/django-developers/194b43ff-98cf-4736-8360-3d79e9b62402n%40googlegroups.com >>>>> >>>>> <https://groups.google.com/d/msgid/django-developers/194b43ff-98cf-4736-8360-3d79e9b62402n%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> -- >>> 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 view this discussion on the web visit >>> https://groups.google.com/d/msgid/django-developers/91e944b1-98cd-4e5e-80e2-f0bad0874f93n%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/django-developers/91e944b1-98cd-4e5e-80e2-f0bad0874f93n%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/aa4d93b4-b1cb-453e-a1a3-7b06c1130b4cn%40googlegroups.com.
