--- title: "Notes de publication de Django 3.2" version: 4.2 locale: fr source: https://docs.djangoproject.com/fr/4.2/releases/3.2/ canonical: https://djangodocs.dev/fr/4.2/releases/3.2/ --- # Notes de publication de Django 3.2 *6 avril 2021* Bienvenue dans Django 3.2 ! Ces notes de publications couvrent les [nouvelles fonctionnalités](#whats-new-3-2), ainsi que certaines [modifications non rétrocompatibles](#backwards-incompatible-3-2) dont il faut être au courant lors la mise à jour depuis Django 3.1 ou des versions plus anciennes. Nous avons commencé [le processus d’obsolescence de certaines fonctionnalités](#deprecated-features-3-2). Voir le guide [Mise à jour de Django à une version plus récente](/fr/4.2/howto/upgrade-version/) si vous mettez à jour un projet existant. Django 3.2 a été désigné comme une [version prise en charge à long terme](/fr/4.2/internals/release-process/#term-Long-term-support-release) (LTS). Elle recevra des mises à jour de sécurité pour au moins 3 ans après sa publication initiale. La prise en charge de la version LTS précédente, Django 2.2, se terminera en avril 2022. ## Compatibilité Python Django 3.2 requiert Python 3.6, 3.7, 3.8, 3.9 ou 3.10 (dès 3.2.9). Nous **recommandons vivement** et nous ne prenons officiellement en charge que la dernière publication de chaque série. ## Quoi de neuf dans Django 3.2 ### Découverte automatique des classes [`AppConfig`](/fr/4.2/ref/applications/#django.apps.AppConfig) La plupart des applications réutilisables définissent une sous-classe de [`AppConfig`](/fr/4.2/ref/applications/#django.apps.AppConfig) dans un sous-module `apps.py`. Elles définissent souvent une variable `default_app_config` pointant vers cette classe dans leur fichier `__init__.py`. Lorsque le sous-module `apps.py` existe et définit une seule sous-classe [`AppConfig`](/fr/4.2/ref/applications/#django.apps.AppConfig), Django utilise dorénavant automatiquement cette configuration, il est donc possible de supprimer `default_app_config`. `default_app_config` rendait possible la déclaration simple du chemin d’application dans [`INSTALLED_APPS`](/fr/4.2/ref/settings/#std-setting-INSTALLED_APPS) (par ex. `'django.contrib.admin'`) au lieu du chemin complet vers la classe de configuration (par ex. `'django.contrib.admin.apps.AdminConfig'`). Cette variable avait été introduite par souci de rétrocompatibilité avec l’ancien style, dans l’intention de basculer l’écosystème dans la syntaxe plus longue, mais ceci ne s’est jamais produit. Avec la découverte automatique des classes `AppConfig`, `default_app_config` n’a plus de raison d’être. Par conséquent, elle a été rendue obsolète. Lisez [Configuration des applications](/fr/4.2/ref/applications/#configuring-applications-ref) pour des informations plus complètes. ### Personnalisation du type des clés primaires auto-générées Lors de la définition d’un modèle, si aucun champ du modèle ne définit [`primary_key=True`](/fr/4.2/ref/models/fields/#django.db.models.Field.primary_key), une clé primaire implicite est créée. Le type de cette clé primaire implicite peut dorénavant être contrôlée par le réglage [`DEFAULT_AUTO_FIELD`](/fr/4.2/ref/settings/#std-setting-DEFAULT_AUTO_FIELD) et l’attribut [`AppConfig.default_auto_field`](/fr/4.2/ref/applications/#django.apps.AppConfig.default_auto_field). Plus besoin de surcharger les clés primaires dans tous les modèles. Afin de conserver le comportement historique, la valeur par défaut de [`DEFAULT_AUTO_FIELD`](/fr/4.2/ref/settings/#std-setting-DEFAULT_AUTO_FIELD) est [`AutoField`](/fr/4.2/ref/models/fields/#django.db.models.AutoField). À partir de la version 3.2, les nouveaux projets sont générés avec [`DEFAULT_AUTO_FIELD`](/fr/4.2/ref/settings/#std-setting-DEFAULT_AUTO_FIELD) définie à [`BigAutoField`](/fr/4.2/ref/models/fields/#django.db.models.BigAutoField). De même, les nouvelles applications sont générées avec [`AppConfig.default_auto_field`](/fr/4.2/ref/applications/#django.apps.AppConfig.default_auto_field) définie à [`BigAutoField`](/fr/4.2/ref/models/fields/#django.db.models.BigAutoField). Dans une future version de Django, la valeur par défaut de [`DEFAULT_AUTO_FIELD`](/fr/4.2/ref/settings/#std-setting-DEFAULT_AUTO_FIELD) sera modifiée en [`BigAutoField`](/fr/4.2/ref/models/fields/#django.db.models.BigAutoField). Pour éviter des migrations non souhaitées dans le futur, définissez explicitement [`DEFAULT_AUTO_FIELD`](/fr/4.2/ref/settings/#std-setting-DEFAULT_AUTO_FIELD) à [`AutoField`](/fr/4.2/ref/models/fields/#django.db.models.AutoField): ``` DEFAULT_AUTO_FIELD = "django.db.models.AutoField" ``` ou configurez ce réglage par application: ``` from django.apps import AppConfig class MyAppConfig(AppConfig): default_auto_field = "django.db.models.AutoField" name = "my_app" ``` ou même encore par modèle: ``` from django.db import models class MyModel(models.Model): id = models.AutoField(primary_key=True) ``` Par anticipation du changement de valeur par défaut, un contrôle système produit un avertissement si vous ne définissez pas explicitement [`DEFAULT_AUTO_FIELD`](/fr/4.2/ref/settings/#std-setting-DEFAULT_AUTO_FIELD) dans votre projet. When changing the value of [`DEFAULT_AUTO_FIELD`](/fr/4.2/ref/settings/#std-setting-DEFAULT_AUTO_FIELD), migrations for the primary key of existing auto-created through tables cannot be generated currently. See the [`DEFAULT_AUTO_FIELD`](/fr/4.2/ref/settings/#std-setting-DEFAULT_AUTO_FIELD) docs for details on migrating such tables. ### Index fonctionnels Le nouveau paramètre positionnel [`*expressions`](/fr/4.2/ref/models/indexes/#django.db.models.Index.expressions) de [`Index()`](/fr/4.2/ref/models/indexes/#django.db.models.Index) permet de créer des index fonctionnels sur la base d’expressions et de fonctions de base de données. Par exemple ``` from django.db import models from django.db.models import F, Index, Value from django.db.models.functions import Lower, Upper class MyModel(models.Model): first_name = models.CharField(max_length=255) last_name = models.CharField(max_length=255) height = models.IntegerField() weight = models.IntegerField() class Meta: indexes = [ Index( Lower("first_name"), Upper("last_name").desc(), name="first_last_name_idx", ), Index( F("height") / (F("weight") + Value(5)), name="calc_idx", ), ] ``` Les index fonctionnels peuvent être ajoutés aux modèles en utilisant l’option [`Meta.indexes`](/fr/4.2/ref/models/options/#django.db.models.Options.indexes). ### Prise en charge de `pymemcache` The new `django.core.cache.backends.memcached.PyMemcacheCache` cache backend allows using the [pymemcache](https://pypi.org/project/pymemcache/) library for memcached. `pymemcache` 3.4.0 or higher is required. For more details, see the [documentation on caching in Django](/fr/4.2/topics/cache/). ### Nouveaux décorateurs pour le site d’administration Le nouveau décorateur [`display()`](/fr/4.2/ref/contrib/admin/#django.contrib.admin.display) permet d’ajouter facilement des options à des fonctions d’affichage personnalisées pouvant être utilisée dans [`list_display`](/fr/4.2/ref/contrib/admin/#django.contrib.admin.ModelAdmin.list_display) ou [`readonly_fields`](/fr/4.2/ref/contrib/admin/#django.contrib.admin.ModelAdmin.readonly_fields). De façon similaire, le nouveau décorateur [`action()`](/fr/4.2/ref/contrib/admin/actions/#django.contrib.admin.action) permet d’ajouter facilement des options à des fonctions d’action pouvant être utilisée dans [`actions`](/fr/4.2/ref/contrib/admin/#django.contrib.admin.ModelAdmin.actions). L’utilisation du décorateur `@display` a l’avantage de rendre possible la syntaxe de décoration `@property` lorsqu’il est nécessaire d’indiquer des attributs à une méthode personnalisée. Avant cela, il était nécessaire d’utiliser la fonction `property()` après la définition des attributs nécessaires à la méthode. L’utilisation de décorateurs a l’avantage de rendre ces options plus accessibles car elles peuvent être suggérées par des utilitaires de complétion dans des éditeurs de code. Ces décorateurs sont de simples commodités et définissent en réalité les mêmes attributs sur les fonctions, sous le capot. ### Fonctionnalités mineures #### [`django.contrib.admin`](/fr/4.2/ref/contrib/admin/#module-django.contrib.admin) - [`ModelAdmin.search_fields`](/fr/4.2/ref/contrib/admin/#django.contrib.admin.ModelAdmin.search_fields) autorise désormais la recherche de phrases contenant des espaces, entre guillemets. - Les champs liés en lecture seule sont maintenant affichés comme des liens navigables si les modèles cibles sont inscrits dans le site d’administration. - Le site d’administration peut maintenant être thématisé, et il contient un thème sombre activé en fonction des réglages du navigateur. Voir [Prise en charge des thèmes](/fr/4.2/ref/contrib/admin/#admin-theming) pour plus de détails. - [`ModelAdmin.autocomplete_fields`](/fr/4.2/ref/contrib/admin/#django.contrib.admin.ModelAdmin.autocomplete_fields) respecte dorénavant attr:ForeignKey.to\_field \ et [`ForeignKey.limit_choices_to`](/fr/4.2/ref/models/fields/#django.db.models.ForeignKey.limit_choices_to) lors de la recherche d’un modèle lié. - Le site d’administration installe doérnavant une vue finale « attrape-tout » qui redirige les utilisateurs non authentifiés vers la page de connexion, que l’URL soit valide ou non. Ceci protège contre une potentielle faille de confidentialité par découverte de modèle. Même si ce n’est pas recommandé, il est possible de définir le nouvel attribut [`AdminSite.final_catch_all_view`](/fr/4.2/ref/contrib/admin/#django.contrib.admin.AdminSite.final_catch_all_view) à `False` pour désactiver cette vue « attrape-tout ». #### [`django.contrib.auth`](/fr/4.2/topics/auth/#module-django.contrib.auth) - Le nombre d’itération par défaut du hacheur de mot de passe PBKDF2 a été augmenté de 216’000 à 260’000. - La variante par défaut du hacheur de mots de passe Argon2 a été changée en Argon2id. `memory_cost` et `parallelism` ont été respectivement augmentées à 102’400 et 8 pour correspondre aux valeurs par défaut de `argon2-cffi`. L’augmentation de la valeur `memory_cost` fait augmenter la mémoire nécessaire de 512 Ko à 100 Mo. C’est toujours plutôt conservateur, mais peut amener à des problèmes de mémoire dans des environnements restreints. Dans ce genre de cas, il est possible de créer une sous-classe du hacheur existant pour surcharger les valeurs par défaut. - L’entropie par défaut du sel des hacheurs de mots de passe Argon2, MD5, PBKDF2 et SHA-1 a été augmentée de 71 à 128 bits. #### [`django.contrib.contenttypes`](/fr/4.2/ref/contrib/contenttypes/#module-django.contrib.contenttypes) - Le nouveau paramètre `absolute_max` de [`generic_inlineformset_factory()`](/fr/4.2/ref/contrib/contenttypes/#django.contrib.contenttypes.forms.generic_inlineformset_factory) permet de personnaliser le nombre maximum de formulaires pouvant être instanciés lors de la soumission de données `POST`. Consultez [Restriction du nombre maximum de formulaires instanciés](/fr/4.2/topics/forms/formsets/#formsets-absolute-max) pour plus de détails. - Le nouveau paramètre `can_delete_extra` de [`generic_inlineformset_factory()`](/fr/4.2/ref/contrib/contenttypes/#django.contrib.contenttypes.forms.generic_inlineformset_factory) permet de supprimer la possibilité de supprimer les formulaires supplémentaires. Voir [`can_delete_extra`](/fr/4.2/topics/forms/formsets/#django.forms.formsets.BaseFormSet.can_delete_extra) pour plus d’informations. #### [`django.contrib.gis`](/fr/4.2/ref/contrib/gis/#module-django.contrib.gis) - La méthode [`GDALRaster.transform()`](/fr/4.2/ref/contrib/gis/gdal/#django.contrib.gis.gdal.GDALRaster.transform) prend dorénavant en charge [`SpatialReference`](/fr/4.2/ref/contrib/gis/gdal/#django.contrib.gis.gdal.SpatialReference). - La classe [`DataSource`](/fr/4.2/ref/contrib/gis/gdal/#django.contrib.gis.gdal.DataSource) prend dorénavant en charge [`pathlib.Path`](https://docs.python.org/3/library/pathlib.html#pathlib.Path). - La classe [`LayerMapping`](/fr/4.2/ref/contrib/gis/layermapping/#django.contrib.gis.utils.LayerMapping) prend dorénavant en charge [`pathlib.Path`](https://docs.python.org/3/library/pathlib.html#pathlib.Path). #### [`django.contrib.postgres`](/fr/4.2/ref/contrib/postgres/#module-django.contrib.postgres) - Le nouvel attribut [`ExclusionConstraint.include`](/fr/4.2/ref/contrib/postgres/constraints/#django.contrib.postgres.constraints.ExclusionConstraint.include) permet de créer des contraintes d’exclusion couvrantes avec PostgreSQL 12+. - Le nouvel attribut [`ExclusionConstraint.opclasses`](/fr/4.2/ref/contrib/postgres/constraints/#django.contrib.postgres.constraints.ExclusionConstraint.opclasses) permet de définir les classes d’opérateurs PostgreSQL. - Le nouvel attribut [`JSONBAgg.ordering`](/fr/4.2/ref/contrib/postgres/aggregates/#django.contrib.postgres.aggregates.JSONBAgg.ordering) détermine l’ordre des éléments agrégés. - Le nouvel attribut [`JSONBAgg.distinct`](/fr/4.2/ref/contrib/postgres/aggregates/#django.contrib.postgres.aggregates.JSONBAgg.distinct) détermine si les valeurs agrégées seront distinctes. - L’opération [`CreateExtension`](/fr/4.2/ref/contrib/postgres/operations/#django.contrib.postgres.operations.CreateExtension) contrôle dorénavant si l’extension existe déjà dans la base de données et saute la migration le cas échéant. - Les nouvelles opérations [`CreateCollation`](/fr/4.2/ref/contrib/postgres/operations/#django.contrib.postgres.operations.CreateCollation) et [`RemoveCollation`](/fr/4.2/ref/contrib/postgres/operations/#django.contrib.postgres.operations.RemoveCollation) permettent de créer et de supprimer des collations avec PostgreSQL. Voir [Gestion des collations à l’aide des migrations](/fr/4.2/ref/contrib/postgres/operations/#manage-postgresql-collations) pour plus de détails. - Les requêtes sur les champs [`ArrayField`](/fr/4.2/ref/contrib/postgres/fields/#django.contrib.postgres.fields.ArrayField) permettent dorénavant des tableaux (non imbriqués) contenant des expressions dans les parties droites des requêtes. - La nouvelle expression [`OpClass()`](/fr/4.2/ref/contrib/postgres/indexes/#django.contrib.postgres.indexes.OpClass) permet de créer des index fonctionnels sur les expressions avec une classe d’opérateur personnalisée. Voir [Index fonctionnels](#new-functional-indexes) pour plus de détails. #### [`django.contrib.sitemaps`](/fr/4.2/ref/contrib/sitemaps/#module-django.contrib.sitemaps) - Les nouveaux attributs [`alternates`](/fr/4.2/ref/contrib/sitemaps/#django.contrib.sitemaps.Sitemap.alternates), [`languages`](/fr/4.2/ref/contrib/sitemaps/#django.contrib.sitemaps.Sitemap.languages) et [`x_default`](/fr/4.2/ref/contrib/sitemaps/#django.contrib.sitemaps.Sitemap.x_default) de [`Sitemap`](/fr/4.2/ref/contrib/sitemaps/#django.contrib.sitemaps.Sitemap) permettent de générer des versions (*alternates*) des plans de sites vers des versions traduites de vos pages. #### [`django.contrib.syndication`](/fr/4.2/ref/contrib/syndication/#module-django.contrib.syndication) - Le nouveau point d’entrée `item_comments` permet d’indiquer une URL de commentaires par élément de flux. #### Moteurs de base de données - Les moteurs de base de données de tierce partie peuvent maintenant sauter des tests ou les marquer comme échecs attendus dans la suite de tests de Django en utilisant les nouveaux attributs DatabaseFeatures.django\_test\_skips\` et `django_test_expected_failures`. #### Décorateurs - Le nouveau décorateur [`no_append_slash()`](/fr/4.2/topics/http/decorators/#django.views.decorators.common.no_append_slash) permet à des vues individuelles d’être exclues de la normalisation des URL par [`APPEND_SLASH`](/fr/4.2/ref/settings/#std-setting-APPEND_SLASH). #### Signalement d’erreurs - Les sous-classes personnalisées de [`ExceptionReporter`](/fr/4.2/howto/error-reporting/#django.views.debug.ExceptionReporter) peuvent maintenant définir les propriétés [`html_template_path`](/fr/4.2/howto/error-reporting/#django.views.debug.ExceptionReporter.html_template_path) et [`text_template_path`](/fr/4.2/howto/error-reporting/#django.views.debug.ExceptionReporter.text_template_path) pour surcharger les gabarits utilisés pour produire les rapports d’exceptions. #### Téléversement de fichiers - La nouvelle fonction de rappel [`FileUploadHandler.upload_interrupted()`](/fr/4.2/ref/files/uploads/#django.core.files.uploadhandler.FileUploadHandler.upload_interrupted) permet de traiter les téléversements interrompus. #### Formulaires - Le nouveau paramètre `absolute_max` de [`formset_factory()`](/fr/4.2/ref/forms/formsets/#django.forms.formsets.formset_factory), [`inlineformset_factory()`](/fr/4.2/ref/forms/models/#django.forms.models.inlineformset_factory) et [`modelformset_factory()`](/fr/4.2/ref/forms/models/#django.forms.models.modelformset_factory) permet de personnaliser le nombre maximum de formulaires pouvant être instanciés lors de la soumission de données `POST`. Voir [Restriction du nombre maximum de formulaires instanciés](/fr/4.2/topics/forms/formsets/#formsets-absolute-max) pour plus de détails. - Le nouveau paramètre `can_delete_extra` de [`formset_factory()`](/fr/4.2/ref/forms/formsets/#django.forms.formsets.formset_factory), [`inlineformset_factory()`](/fr/4.2/ref/forms/models/#django.forms.models.inlineformset_factory) et [`modelformset_factory()`](/fr/4.2/ref/forms/models/#django.forms.models.modelformset_factory) permet d’enlever la possibilité de supprimer les formulaires supplémentaires. Voir [`can_delete_extra`](/fr/4.2/topics/forms/formsets/#django.forms.formsets.BaseFormSet.can_delete_extra) pour plus d’informations. - Lorsqu’un formulaire de gestion est manquant ou a été manipulé, [`BaseFormSet`](/fr/4.2/topics/forms/formsets/#django.forms.formsets.BaseFormSet) signale dorénavant une erreur à l’utilisateur plutôt que de produire une exception. Pour personnaliser le message d’erreur, passez le paramètre `error_messages` avec la clé `'missing_management_form'` lors de l’instanciation du jeu de formulaires. #### Vues génériques - Les attributs `week_format` de class:~django.views.generic.dates.WeekMixin et [`WeekArchiveView`](/fr/4.2/ref/class-based-views/generic-date-based/#django.views.generic.dates.WeekArchiveView) prennent désormais en charge le format de semaine ISO 8601 `'%V'`. #### Commandes d’administration - [`loaddata`](/fr/4.2/ref/django-admin/#django-admin-loaddata) prend désormais en charge les instantanés stockés dans des archives XZ (`.xz`) et LZMA (`.lzma`). - [`dumpdata`](/fr/4.2/ref/django-admin/#django-admin-dumpdata) sait désormais comprimer les données dans les formats `bz2`, `gz`, `lzma` ou `xz`. - [`makemigrations`](/fr/4.2/ref/django-admin/#django-admin-makemigrations) peut désormais être appelée sans connexion active de base de données. Dans ce cas, le contrôle de cohérence de l’historique des migrations est omis. - [`BaseCommand.requires_system_checks`](/fr/4.2/howto/custom-management-commands/#django.core.management.BaseCommand.requires_system_checks) peut dorénavant accepter une liste d’étiquettes. Les contrôles système inscrits avec les étiquettes choisies seront appliqués avant d’exécuter la commande. Dans les versions précédentes, soit tous les contrôles systèmes étaient appliqués, soit aucun. - La prise en charge des contenus de terminal colorés sous Windows a été mise à jour. Différents environnements de terminal modernes sont automatiquement détectés, et les options pour activer la prise en charge dans d’autre cas ont été améliorées. Voir [Syntaxe colorée](/fr/4.2/ref/django-admin/#syntax-coloring) pour plus de détails. #### Migrations - La nouvelle propriété `Operation.migration_name_fragment` permet de fournir un fragment de nom de fichier qui sera utilisé pour nommer une migration contenant uniquement cette opération. - Les migrations prennent désormais en charge la sérialisation des objets chemins purs et concrets des instances [`pathlib`](https://docs.python.org/3/library/pathlib.html#module-pathlib) et [`os.PathLike`](https://docs.python.org/3/library/os.html#os.PathLike). #### Modèles - Le nouveau paramètre `no_key` de [`QuerySet.select_for_update()`](/fr/4.2/ref/models/querysets/#django.db.models.query.QuerySet.select_for_update), pris en charge par PostgreSQL, permet d’acquérir des verrous plus faibles qui ne bloquent pas la création de lignes référençant des lignes verrouillées au travers d’une clé étrangère. - L’expression [`When()`](/fr/4.2/ref/models/conditional-expressions/#django.db.models.expressions.When) autorise dorénavant l’utilisation du paramètre `condition` avec `lookups`. - Les nouveaux attributs [`Index.include`](/fr/4.2/ref/models/indexes/#django.db.models.Index.include) et [`UniqueConstraint.include`](/fr/4.2/ref/models/constraints/#django.db.models.UniqueConstraint.include) permettent de créer des index couvrants et des contraintes de couverture uniques avec PostgreSQL 11+. - Le nouvel attribut [`UniqueConstraint.opclasses`](/fr/4.2/ref/models/constraints/#django.db.models.UniqueConstraint.opclasses) permet de définir des classes d’opérateur PostgreSQL. - La méthode [`QuerySet.update()`](/fr/4.2/ref/models/querysets/#django.db.models.query.QuerySet.update) respecte dorénavant la clause `order_by()` avec MySQL et MariaDB. - [`FilteredRelation()`](/fr/4.2/ref/models/querysets/#django.db.models.FilteredRelation) prend désormais en charge les relations imbriquées. - Le paramètre `of` de [`QuerySet.select_for_update()`](/fr/4.2/ref/models/querysets/#django.db.models.query.QuerySet.select_for_update) est désormais autorisé avec MySQL 8.0.1+. - L’expression [`Value()`](/fr/4.2/ref/models/expressions/#django.db.models.Value) résout désormais automatiquement sa valeur `output_field` à la sous-classe appropriée de [`Field`](/fr/4.2/ref/models/fields/#django.db.models.Field), en fonction du type de la valeur `value` fournie, pour les types [`bool`](https://docs.python.org/3/library/functions.html#bool), [`bytes`](https://docs.python.org/3/library/stdtypes.html#bytes), [`float`](https://docs.python.org/3/library/functions.html#float), [`int`](https://docs.python.org/3/library/functions.html#int), [`str`](https://docs.python.org/3/library/stdtypes.html#str), [`datetime.date`](https://docs.python.org/3/library/datetime.html#datetime.date), [`datetime.datetime`](https://docs.python.org/3/library/datetime.html#datetime.datetime), [`datetime.time`](https://docs.python.org/3/library/datetime.html#datetime.time), [`datetime.timedelta`](https://docs.python.org/3/library/datetime.html#datetime.timedelta), [`decimal.Decimal`](https://docs.python.org/3/library/decimal.html#decimal.Decimal) et [`uuid.UUID`](https://docs.python.org/3/library/uuid.html#uuid.UUID). Par conséquent, la résolution de `output_field` pour les fonctions de base de données et les expressions combinatoires peuvent désormais planter avec des types mélangés lors de l’utilisation de `Value()`. Dans de tels cas, il sera nécessaire de définir explicitement le type de champ `output_field`. - La nouvelle méthode [`QuerySet.alias()`](/fr/4.2/ref/models/querysets/#django.db.models.query.QuerySet.alias) permet de créer des alias réutilisables pour des expressions qui n’ont pas besoin d’être sélectionnées mais qui sont utiles pour le filtrage, le tri ou comme faisant partie d’expressions complexes. - La nouvelle fonction [`Collate`](/fr/4.2/ref/models/database-functions/#django.db.models.functions.Collate) permet de filtrer et de trier en respectant les collations de base de données indiquées. - Le paramètre `field_name` de [`QuerySet.in_bulk()`](/fr/4.2/ref/models/querysets/#django.db.models.query.QuerySet.in_bulk) accepte dorénavant les champs distincts s’il n’existe qu’un seul champ indiqué dans [`QuerySet.distinct()`](/fr/4.2/ref/models/querysets/#django.db.models.query.QuerySet.distinct). - Le nouveau paramètre `tzinfo` des fonctions de base de données [`TruncDate`](/fr/4.2/ref/models/database-functions/#django.db.models.functions.TruncDate) et [`TruncTime`](/fr/4.2/ref/models/database-functions/#django.db.models.functions.TruncTime) permettent de tronquer les dates/heures dans un fuseau horaire déterminé. - Le nouveau paramètre `db_collation` de [`CharField`](/fr/4.2/ref/models/fields/#django.db.models.CharField.db_collation) et:attr:TextField \ permet de définir une collation de base de données pour le champ. - La fonction de base de données [`Random`](/fr/4.2/ref/models/database-functions/#django.db.models.functions.Random) a été ajoutée. - Les [Fonctions d’agrégation](/fr/4.2/ref/models/querysets/#aggregation-functions), [`F()`](/fr/4.2/ref/models/expressions/#django.db.models.F), [`OuterRef()`](/fr/4.2/ref/models/expressions/#django.db.models.OuterRef) et d’autres expressions autorisent désormais l’utilisation de transformations. Voir [Les expressions peuvent référencer des transformations](/fr/4.2/topics/db/queries/#using-transforms-in-expressions) pour plus de détails. - Le nouveau paramètre `durable` de [`atomic()`](/fr/4.2/topics/db/transactions/#django.db.transaction.atomic) garantit que les modifications effectuées dans le bloc atomique seront validées si le bloc se termine sans erreur. Un bloc atomique imbriqué marqué comme durable produira une exception `RuntimeError`. - La fonction de base de données [`JSONObject`](/fr/4.2/ref/models/database-functions/#django.db.models.functions.JSONObject) a été ajoutée. #### Pagination - La nouvelle méthode [`django.core.paginator.Paginator.get_elided_page_range()`](/fr/4.2/ref/paginator/#django.core.paginator.Paginator.get_elided_page_range) permet de générer un intervalle de pages avec certaines valeurs éludées. Lorsqu’il y a beaucoup de pages, ceci peut s’avérer utile pour générer un nombre raisonnable de liens vers des pages dans un gabarit. #### Requêtes et réponses - Les en-têtes de réponses sont désormais stockées dans [`HttpResponse.headers`](/fr/4.2/ref/request-response/#django.http.HttpResponse.headers). Ceci peut remplacer l’accès traditionnel par interface de style dictionnaire des objets `HttpResponse`. Les deux interfaces continueront a être prises en charge. Voir [Définition de champs d’en-tête](/fr/4.2/ref/request-response/#setting-header-fields) pour plus de détails. - Le nouveau paramètre `headers` de class:~django.http.HttpResponse, [`SimpleTemplateResponse`](/fr/4.2/ref/template-response/#django.template.response.SimpleTemplateResponse) et [`TemplateResponse`](/fr/4.2/ref/template-response/#django.template.response.TemplateResponse) permet de définir les en-têtes de réponse [`headers`](/fr/4.2/ref/request-response/#django.http.HttpResponse.headers) lors de l’instanciation. #### Sécurité - Le contenu du réglage [`SECRET_KEY`](/fr/4.2/ref/settings/#std-setting-SECRET_KEY) est dorénavant vérifié lors de son premier accès, plutôt qu’au moment du chargement des réglages. Ceci permet aux commandes d’administration qui ne dépendent pas de `SECRET_KEY` de s’exécuter sans qu’une valeur soit définie. Par suite de ce changement, l’appel à [`configure()`](/fr/4.2/topics/settings/#django.conf.settings.configure) sans fournir de `SECRET_KEY` valable, puis poursuivre en accédant plus tard à `settings.SECRET_KEY` produira une exception [`ImproperlyConfigured`](/fr/4.2/ref/exceptions/#django.core.exceptions.ImproperlyConfigured). - Les nouvelles méthodes `Signer.sign_object()` et `Signer.unsign_object()` permettent de signer des structures complexes. Voir [Protection de structures de données complexes](/fr/4.2/topics/signing/#signing-complex-data) pour plus de détails. De plus, [`signing.dumps()`](/fr/4.2/topics/signing/#django.core.signing.dumps) et [`loads()`](/fr/4.2/topics/signing/#django.core.signing.loads) deviennent des raccourcis de [`TimestampSigner.sign_object()`](/fr/4.2/topics/signing/#django.core.signing.TimestampSigner.sign_object) et [`unsign_object()`](/fr/4.2/topics/signing/#django.core.signing.TimestampSigner.unsign_object). #### Sérialisation - Le nouveau sérialiseur [JSONL](/fr/4.2/topics/serialization/#serialization-formats-jsonl) permet d’utiliser le format de lignes JSON avec [`dumpdata`](/fr/4.2/ref/django-admin/#django-admin-dumpdata) et [`loaddata`](/fr/4.2/ref/django-admin/#django-admin-loaddata). Cela peut être utile pour remplir de grosses bases de données, car les données sont chargées ligne par ligne en mémoire plutôt que d’être chargées d’un coup en entier. #### Signaux - [`Signal.send_robust()`](/fr/4.2/topics/signals/#django.dispatch.Signal.send_robust) journalise dorénavant les exceptions. #### Gabarits - Le filtre de gabarit [`floatformat`](/fr/4.2/ref/templates/builtins/#std-templatefilter-floatformat) permet dorénavant d’utiliser le suffixe `g` pour forcer le groupement par [`THOUSAND_SEPARATOR`](/fr/4.2/ref/settings/#std-setting-THOUSAND_SEPARATOR) pour la locale active. - Les gabarits mis en cache avec les [chargeurs de gabarits en cache](/fr/4.2/ref/templates/api/#template-loaders) sont dorénavant rechargés correctement en mode développement. #### Tests - Les objets attribués à des attributs de classe dans [`TestCase.setUpTestData()`](/fr/4.2/topics/testing/tools/#django.test.TestCase.setUpTestData) sont maintenant isolés pour chaque méthode de test. De tels objets doivent maintenant être capables de prendre en charge la copie profonde par [`copy.deepcopy()`](https://docs.python.org/3/library/copy.html#copy.deepcopy). L’attribution d’objets qui ne prennent pas en charge `deepcopy()` est obsolète et sera supprimée dans Django 4.1. - [`DiscoverRunner`](/fr/4.2/topics/testing/advanced/#django.test.runner.DiscoverRunner) active dorénavant [`faulthandler`](https://docs.python.org/3/library/faulthandler.html#module-faulthandler) par défaut. Ceci peut être désactivé en utilisant l’option [`test --no-faulthandler`](/fr/4.2/ref/django-admin/#cmdoption-test-no-faulthandler). - [`DiscoverRunner`](/fr/4.2/topics/testing/advanced/#django.test.runner.DiscoverRunner) et la commande d’administration [`test`](/fr/4.2/ref/django-admin/#django-admin-test) peut dorénavant mesurer des temps d’exécution, y compris la mise en place de la base de données et le temps total d’exécution. Ceci peut être activé en utilisant l’option [`test --timing`](/fr/4.2/ref/django-admin/#cmdoption-test-timing). - [`Client`](/fr/4.2/topics/testing/tools/#django.test.Client) préserve dorénavant la chaîne de requête lorsqu’il suit des redirections 307 et 308. - La nouvelle méthode [`TestCase.captureOnCommitCallbacks()`](/fr/4.2/topics/testing/tools/#django.test.TestCase.captureOnCommitCallbacks) capture dans une liste les fonctions de rappel transmises à [`transaction.on_commit()`](/fr/4.2/topics/db/transactions/#django.db.transaction.on_commit) . Cela permet de tester de telles fonctions de rappel sans devoir utiliser la classe [`TransactionTestCase`](/fr/4.2/topics/testing/tools/#django.test.TransactionTestCase) plus lente. - [`TransactionTestCase.assertQuerysetEqual()`](/fr/4.2/topics/testing/tools/#django.test.TransactionTestCase.assertQuerySetEqual) now supports direct comparison against another queryset rather than being restricted to comparison against a list of string representations of objects when using the default value for the `transform` argument. #### Utilitaires - Le nouveau paramètre `depth` des fonctions `django.utils.timesince.timesince()` et `django.utils.timesince.timeuntil()` permet d’indiquer le nombre d’unités de temps adjacentes à renvoyer. #### Validateurs - Les validateurs intégrés incluent dorénavant la valeur fournie dans l’argument `params` d’une erreur [`ValidationError`](/fr/4.2/ref/exceptions/#django.core.exceptions.ValidationError). Cela permet à des messages d’erreur personnalisés d’utiliser le substituant `%(value)s`. - L’opérateur d’égalité de [`ValidationError`](/fr/4.2/ref/exceptions/#django.core.exceptions.ValidationError) ignore dorénavant l’ordre dans `messages` et `params`. ## Changements incompatibles avec les anciennes versions dans Django 3.2 ### API de moteur de base de données Cette section décrit des modifications qui pourraient être nécessaires dans des moteurs de base de données tiers. - La nouvelle propriété `DatabaseFeatures.introspected_field_types` remplace ces capacités : - `can_introspect_autofield` - `can_introspect_big_integer_field` - `can_introspect_binary_field` - `can_introspect_decimal_field` - `can_introspect_duration_field` - `can_introspect_ip_address_field` - `can_introspect_positive_integer_field` - `can_introspect_small_integer_field` - `can_introspect_time_field` - `introspected_big_auto_field_type` - `introspected_small_auto_field_type` - `introspected_boolean_field_type` - Pour activer la prise en charge des index couvrants ([`Index.include`](/fr/4.2/ref/models/indexes/#django.db.models.Index.include)) et les contraintes de couverture uniques ([`UniqueConstraint.include`](/fr/4.2/ref/models/constraints/#django.db.models.UniqueConstraint.include)), définissez `DatabaseFeatures.supports_covering_indexes` à `True`. - Les moteurs de base de données externes doivent implémenter la prise en charge des collations de colonnes de base de données pour `CharField` et `TextField` ou définir `DatabaseFeatures.supports_collation_on_charfield` et `DatabaseFeatures.supports_collation_on_textfield` à `False`. Si les collations non déterministes ne sont pas prises en charge, définissez `supports_non_deterministic_collations` à `False`. - `DatabaseOperations.random_function_sql()` a été supprimée en faveur de la nouvelle fonction de base de données [`Random`](/fr/4.2/ref/models/database-functions/#django.db.models.functions.Random). - `DatabaseOperations.date_trunc_sql()` et `DatabaseOperations.time_trunc_sql()` acceptent dorénavant le paramètre facultatif `tzname` afin de tronquer dans un fuseau horaire bien précis. - `DatabaseClient.runshell()` obtient dorénavant les arguments et un dictionnaire facultatif de variables d’environnement pour le client en ligne de commande sous-jacent à partir de la méthode `DatabaseClient.settings_to_cmd_args_env()`. Les moteurs de bases de données tiers doivent implémenter `DatabaseClient.settings_to_cmd_args_env()` ou surcharger `DatabaseClient.runshell()`. - Les moteurs de bases de données tiers doivent implémenter la prise en charge des index fonctionnels ([`Index.expressions`](/fr/4.2/ref/models/indexes/#django.db.models.Index.expressions)) ou définir `DatabaseFeatures.supports_expression_indexes` à `False`. Si `COLLATE` ne fait pas partie de l’instruction `CREATE INDEX`, définissez `DatabaseFeatures.collate_as_index_expression` à `True`. ### [`django.contrib.admin`](/fr/4.2/ref/contrib/admin/#module-django.contrib.admin) - Les liens de pagination dans le site d’administration sont dorénavant indicées à partir de 1 au lieu de 0, c’est-à-dire que la chaîne de requête de la première page est `?p=1` au lieu de `?p=0`. - La nouvelle vue « attrape-tout » du site d’administration casse les motifs d’URL routés après les URL d’administration et dont le préfixe correspond à celui de l’administration. Vous pouvez alors soit ajuster l’ordre de vos URL ou si nécessaire définir [`AdminSite.final_catch_all_view`](/fr/4.2/ref/contrib/admin/#django.contrib.admin.AdminSite.final_catch_all_view) à `False`, désactivant ainsi la vue « attrape-tout ». Voir [Quoi de neuf dans Django 3.2](#whats-new-3-2) pour plus de détails. - Les fichiers JavaScript minifiés ne sont plus inclus avec le site d’administration. Si vous devez avoir accès à ces fichiers minifiés, considérez l’utilisation d’une application tierce ou d’un outil de construction externe. Il reste cependant dans le site d’administration la version minifiée des bibliothèques JavaScript externes (par ex. [jquery.min.js](/fr/4.2/ref/contrib/admin/#contrib-admin-jquery)). - [`ModelAdmin.prepopulated_fields`](/fr/4.2/ref/contrib/admin/#django.contrib.admin.ModelAdmin.prepopulated_fields) n’exclut plus les mots vides anglais tels que `'a'` ou `'an'`. ### [`django.contrib.gis`](/fr/4.2/ref/contrib/gis/#module-django.contrib.gis) - La prise en charge de PostGIS 2.2 a été supprimée. - Le moteur Oracle clone dorénavant les polygones (et les collections géométriques contenant des polygones) avant de les réorienter et de les enregistrer en base de données. Ils ne sont plus modifiés eux-mêmes. Cela peut se remarquer quand on utilise des polygones après l’enregistrement d’un modèle. ### Abandon de la prise en charge de PostgreSQL 9.5 La prise en charge amont de PostgreSQL 9.5 se termine en février 2021. Django 3.2 prend en charge PostgreSQL 9.6 et plus récent. ### Abandon de la prise en charge de MySQL 5.6 La fin de la prise en charge amont de MySQL 5.6 est en avril 2021. Django 3.2 prend en charge MySQL 5.7 et plus récent. ### Divers - Django prend dorénavant en charge les fuseaux horaires non-`pytz`, tels que ceux du module [`zoneinfo`](https://docs.python.org/3/library/zoneinfo.html#module-zoneinfo) de Python 3.9+ et ses rétroportages. - La méthode non documentée `SpatiaLiteOperations.proj4_version()` a été renommée en `proj_version()`. - [`slugify()`](/fr/4.2/ref/utils/#django.utils.text.slugify) supprime dorénavant les tirets et soulignements en début et fin de texte. - The [`intcomma`](/fr/4.2/ref/contrib/humanize/#std-templatefilter-intcomma) and [`intword`](/fr/4.2/ref/contrib/humanize/#std-templatefilter-intword) template filters no longer depend on the `USE_L10N` setting. - La prise en charge de `argon2-cffi` \< 19.1.0 a été abandonnée. - Les clés de cache ne contiennent plus la langue lorsque l’internationalisation est désactivée (`USE_I18N = False`) et que la régionalisation est activée (`USE_L10N = True`). Après la mise à jour vers Django 3.2 dans une configuration telle que celle-ci, la première requête vers une valeur précédemment en cache produira un défaut de cache. - `ForeignKey.validate()` utilise dorénavant [`_base_manager`](/fr/4.2/topics/db/managers/#django.db.models.Model._base_manager) au lieu de [`_default_manager`](/fr/4.2/topics/db/managers/#django.db.models.Model._default_manager) pour vérifier si des instances liées existent. - Lorsqu’une application définit une sous-classe de [`AppConfig`](/fr/4.2/ref/applications/#django.apps.AppConfig) dans un sous-module `apps.py`, Django utilise désormais automatiquement cette configuration, même si elle n’est pas activée avec `default_app_config`. Définisez `default = False` dans la sous-classe de [`AppConfig`](/fr/4.2/ref/applications/#django.apps.AppConfig) si vous voulez empêcher ce comportement. Voir [Quoi de neuf dans Django 3.2](#whats-new-3-2) pour plus de détails. - L’instanciation d’un modèle abstrait produit dorénavant une erreur `TypeError`. - Les arguments nommés de [`setup_databases()`](/fr/4.2/topics/testing/advanced/#django.test.utils.setup_databases) sont dorénavant exclusivement des arguments nommés. - La fonction non documentée `django.utils.http.limited_parse_qsl()` a été supprimée. Utilisez [`urllib.parse.parse_qsl()`](https://docs.python.org/3/library/urllib.parse.html#urllib.parse.parse_qsl) à la place. - `django.test.utils.TestContextDecorator` utilise dorénavant [`addCleanup()`](https://docs.python.org/3/library/unittest.html#unittest.TestCase.addCleanup) afin que les nettoyages inscrits dans la méthode [`setUp()`](https://docs.python.org/3/library/unittest.html#unittest.TestCase.setUp) soient appelés avant `TestContextDecorator.disable()`. - `SessionMiddleware` produit dorénavant l’exception exc:~django.contrib.sessions.exceptions.SessionInterrupted au lieu de [`SuspiciousOperation`](/fr/4.2/ref/exceptions/#django.core.exceptions.SuspiciousOperation) lorsqu’une session est détruite dans une requête concurrente. - L’opérateur d’égalité de [`django.db.models.Field`](/fr/4.2/ref/models/fields/#django.db.models.Field) distingue dorénavant correctement les instances de champ héritées entre modèles. De plus, l’ordre de tels champs est dorénavant défini. - La fonction non documentée `django.core.files.locks.lock()` renvoie dorénavant `False` si le fichier ne peut être verrouillé, au lieu de produire l’exception [`BlockingIOError`](https://docs.python.org/3/library/exceptions.html#BlockingIOError). - Le mécanisme de réinitialisation de mot de passe invalide dorénavant les jetons lorsque l’adresse de courriel d’un utilisateur change. - La commande [`makemessages`](/fr/4.2/ref/django-admin/#django-admin-makemessages) ne traite plus les locales non valables indiquées par l’option [`makemessages --locale`](/fr/4.2/ref/django-admin/#cmdoption-makemessages-locale), notamment lorsqu’elles contiennent des tirets (`'-'`). - Le champ de formulaire `django.contrib.auth.forms.ReadOnlyPasswordHashField` est dorénavant désactivé par défaut. Par conséquent, `UserChangeForm.clean_password()` n’est plus nécessaire pour renvoyer la valeur initiale. - Les opérations de cache `cache.get_many()`, `get_or_set()`, `has_key()`, `incr()`, `decr()`, `incr_version()` et `decr_version()` gèrent maintenant correctement les valeurs `None` stockées dans le cache, comme pour toute autre valeur, au lieu de faire comme si la clé n’existait pas dans le cache. En raison d’une limitation de `python-memcached`, le comportement précédent a été conservé pour le moteur obsolète `MemcachedCache`. - La version minimum de SQLite prise en charge est passée de 3.8.3 à 3.9.0. - [`CookieStorage`](/fr/4.2/ref/contrib/messages/#django.contrib.messages.storage.cookie.CookieStorage) stocke dorénavant ses messages dans le format compatible [**RFC 6265**](https://datatracker.ietf.org/doc/html/rfc6265.html). La prise en charge des cookies utilisant l’ancien format est conservée jusqu’à Django 4.1. - La version minimum de `asgiref` prise en charge est passée de 3.2.10 à 3.3.2. ## Fonctionnalités rendues obsolètes dans Django 3.2 ### Divers - L’attribution d’objets ne prenant pas en charge la création de copies profondes avec [`copy.deepcopy()`](https://docs.python.org/3/library/copy.html#copy.deepcopy) à des attributs de classe de [`TestCase.setUpTestData()`](/fr/4.2/topics/testing/tools/#django.test.TestCase.setUpTestData) est obsolète. - L’utilisation d’une valeur booléenne dans attr:.BaseCommand.requires\_system\_checks est osbolète. Utilisez `'__all__'` au lieu de `True`, et `[]` (une liste vide) au lieu de `False`. - L’argument `whitelist` et l’attribut `domain_whitelist` de [`EmailValidator`](/fr/4.2/ref/validators/#django.core.validators.EmailValidator) sont obsolètes. Utilisez `allowlist` au lieu de `whitelist` et `domain_allowlist` au lieu de `domain_whitelist`. Il se peut que vous deviez renommer `whitelist` dans des migrations existantes. - La variable de configuration d’application `default_app_config` est osbolète, en raison de l’ajout de la découverte automatique des classes `AppConfig`. Consultez [Quoi de neuf dans Django 3.2](#whats-new-3-2) pour plus de détails. - L’appel automatique à `repr()` sur un jeu de requête dans `TransactionTestCase.assertQuerysetEqual()` lors de la comparaison avec des chaînes est obsolète. SI vous avez besoin du comportement précédent, définissez explicitement `transform` à `repr`. - Le moteur `django.core.cache.backends.memcached.MemcachedCache` est obsolète car `python-memcached` présente quelques problèmes et ne semble actuellement plus maintenu. Utilisez plutôt `django.core.cache.backends.memcached.PyMemcacheCache` ou `django.core.cache.backends.memcached.PyLibMCCache`. - Le format des messages utilisé par `django.contrib.messages.storage.cookie.CookieStorage` est différent du format généré par les anciennes versions de Django. La prise en charge de l’ancien format demeure jusqu’à Django 4.1.