[WayToDoor]

While it doesn't seem like a major update at first glance on this news piece, the changelog is available here : https://docs.djangoproject.com/en/4.0/releases/4.0/

Of note, in my opinion :

- The new AddConstraintNotValid operation allows creating check constraints on PostgreSQL without verifying that all existing rows satisfy the new constraint, meaning that one can now create constraints on big postgres tables without a waiting period.

- Async methods are coming, to cache for now but hopefully soon to the ORM. They are prefixed with a `a` in the name

- DeleteView now uses FormMixin, allowing you to provide a Form subclass, with a checkbox for example, to confirm deletion. In addition, this allows DeleteView to function with django.contrib.messages.views.SuccessMessageMixin. This is a big thing if you use DeleteViews, as you can now easily show a message post-deletion to the user.

[fleetfox]

Do you know if the ORM solution have the same `a` suffix for async interface? I really hope there is more elegant solution for all this.

[deckiedan]

Yes - it's kinda ugly at the moment, having all the `a` prefixed functions - but I think it's intended as a kind of long-term-intermediate step - since the whole of django isn't async at the moment, and needs to have separate versions for everything.

I (wildly) speculate that once the ORM is async too, and all the rest of the bits fall into place (maybe django 5?), maybe django 6 will drop the `a` prefixes and integrate it all back together somehow?

[samwillis]

I believe they chose the 'a...' pattern as it matches other apis in the standard library - it also makes it explicit but concise.

I can't see it being dropped any time the future, Django will always have a sync api, that won't be dropped. And there is no way in (current) python to combine a sync and async api into a single method.

[cdrx]

ORM will use the same `a` suffix, yes.