Nouveautés de mssql-django

Cet article décrit les nouvelles fonctionnalités, améliorations et modifications apportées à chaque version du back-end de base de mssql-django données Django.

Version 2.0

Date de sortie : septembre 2026

La version 2.0 ajoute le pilote Microsoft mssql-python comme alternative pour chaque base de données à pyodbc, met à jour la matrice de compatibilité prise en charge pour Python, Django et SQL Server, et inclut des correctifs de compatibilité et de fiabilité. pyodbc reste le pilote par défaut.

Points forts

  • Prise en charge du pilote mssql-python : Un alias de base de données active cette prise en charge avec "python_driver": "mssql_python" dans son dictionnaire OPTIONS. Le pilote couvre les connexions, le pool de connexions, les nouvelles tentatives, les transactions et les points de sauvegarde, les valeurs datetimeoffset, l’introspection et l’authentification Microsoft Entra. Les alias qui omettent l’option continuent d’utiliser pyodbc, donc rien ne change tant que vous ne vous inscrivez pas. Pour plus d’informations, voir Sélectionner le pilote de base de données pour mssql-django.
  • Aucune installation séparée du pilote ODBC n’est nécessaire avec mssql-python : un alias sur mssql-python ne nécessite pas l’installation séparée du pilote Microsoft ODBC pour SQL Server. Les alias qui restent activés pyodbc le font toujours.
  • Matrice de support modernisée : Python 3.10 à 3.14, Django 5.2 à 6.1, et SQL Server 2017 à 2025. Django 6.0 et versions ultérieures nécessitent Python 3.12 ou une version ultérieure.

Corrections de bugs

  • Les paramètres explicites de MARS sont respectés : une valeur explicite MARS_Connection dans extra_params est préservée au lieu d’être écrasée par le défaut de Windows, et la correspondance ignore la casuscule. Le paramètre MARS_Connection=no fonctionne désormais contre les terminaux qui rejettent MARS, y compris Microsoft Fabric Warehouse. Avec MARS désactivé, l’itération ORM met les résultats en mémoire tampon avant de les renvoyer, afin qu’une requête imbriquée puisse réutiliser la connexion, ce qui consomme davantage de mémoire avec de grands jeux de résultats. Cette correction de connexion n'ajoute pas un support complet de l'Warehouse pour les migrations ou autres fonctionnalités de SQL Server.
  • Les caractères génériques entre crochets sont échappés dans les recherches basées sur des expressions : les recherches de motifs qui comparent deux champs avec l’expression F(), comme contains et startswith, échappent au caractère générique SQL Server [. Les crochets sont traités comme des données plutôt que comme une syntaxe de caractères génériques.
  • Les apostrophes sont protégées par un caractère d’échappement dans les noms de schéma inspectdb : une apostrophe dans la valeur inspectdb --schema est protégée par un caractère d’échappement dans la requête de métadonnées, de sorte que les noms de schéma contenant une apostrophe ne produisent plus de Transact-SQL (T-SQL) mal formé.
  • Un HOST vide se connecte à localhost dans le backend mssql-python : un HOST, omis, que Django remplit par une chaîne vide, est résolu en localhost au lieu d’entraîner un échec de validation avec une valeur SERVER= vide. Ce comportement correspond à celui pyodbc par défaut pour les instances locales.

Improvements

  • pytz remplacé par zoneinfo et tzdata : la gestion des fuseaux horaires utilise le module de bibliothèque zoneinfo standard, le tzdata paquet fournissant la base de données IANA dans des environnements qui n'en livrent pas, comme Windows et des images de conteneurs minimales. Les décalages restent corrects tout au long de l’année pour les zones avec des décalages négatifs sur l’heure d’été. pytz ce n’est plus une dépendance.
  • Les versions plus récentes de SQL Server sont acceptées : une version majeure de SQL Server que le backend ne reconnaît pas utilise le dernier ensemble de capacités que le backend connaît au lieu de défaillir la validation de version. Vous pouvez vous connecter à une nouvelle version SQL Server avant qu’une version correspondante mssql-django ne soit lancée. Accepter la connexion ne déclare pas les fonctionnalités non testées comme supportées.

Modifications majeures

  • Python 3.8 et 3.9, ainsi que Django 3.2 à 5.1, ne sont plus pris en charge. Le code de compatibilité des versions antérieures reste en place, mais ces combinaisons ne sont ni testées ni listées.
  • mssql-python 1.15.0 ou une version ultérieure est une dépendance requise même lorsqu’un alias utilise pyodbc. L’installation est limitée aux plateformes disposant d’une distribution compatible mssql-python , ce qui exclut SUSE Linux sur ARM64. Les projets sur d’autres plateformes restent sur la version 1.8.0.
  • Le support déclaré de SQL Server commence avec SQL Server 2017, et le support de la connectivité native déclaré est limité au pilote ODBC 17 de Microsoft et au pilote ODBC 18 de Microsoft.

Version 1.8.0

Date de sortie : août 2026

La version 1.8.0 ajoute le support de Django 6.1 tout en continuant de prendre en charge Django 3.2 à 6.0. Déplacer un projet de Django 6.0 à 6.1 ne nécessite aucun changement de code à moins d’utiliser l’une des deux fonctionnalités de Django 6.1 décrites dans cette section.

Points forts

  • Soutien Django 6.1 : Validé contre Django 6.1 tout en continuant à soutenir Django 3.2 à 6.0. La contrainte de dépendance s’élargit de django>=3.2,<6.1 à django>=3.2,<6.2.
  • Utilisation quote_name du compilateur de requêtes sur Django 6.1 : Django 6.1 obsolète quote_name_unless_alias. Le backend appelle désormais SQLCompiler.quote_name avec Django 6.1 et les versions ultérieures, en fonction de la version, de sorte que les versions antérieures de Django restent inchangées. Les requêtes avec découpage et décalage, telles que qs[a:b] et OFFSET ... FETCH, compilent sans avertissements de dépréciation.
  • L’introspection des clés étrangères renvoie la règle ON DELETE : Django 6.1 étend get_relations() pour inclure la règle ON DELETE à l’échelle de la base de données. Le backend restitue la forme attendue en trois parties et mappe les clés étrangères de SQL Server NO ACTION en conséquence, de sorte inspectdb qu’une introspection des clés étrangères produit des modèles corrects.

Fonctionnalités de Django 6.1 qui ne sont pas prises en charge

Deux nouveautés de Django 6.1 ne sont pas disponibles dans ce backend, pour différentes raisons :

  • Actions référentielles au niveau de la base de données (DB_CASCADE, DB_SET_NULL, DB_SET_DEFAULT) : SQL Server rejette les graphes à clé étrangère avec plusieurs chemins en cascade vers la même table (erreur 1785), il n'existe donc pas de chemin natif pour cette fonctionnalité sur aucune version de SQL Server. Utiliser l’une de ces valeurs augmente la vérification fields.E324du système Django , ce qui vous dirige vers le niveau on_deletestandard de Django .
  • Agrégats bit à bit (BitAnd, BitOr, BitXor) : SQL Server n'a pas de fonction native d'agrégation bit à bit, et le backend ne les émule pas, donc ces agrégats génèrent NotSupportedError.

Pour plus d’informations, consultez Limitations et fonctionnalités non prises en charge dans mssql-django.

Version 1.7.4

Date de sortie : juillet 2026

La version 1.7.4 est une version de correctifs rétrocompatibles avec deux correctifs pour la gestion des requêtes brutes et annotées GROUP BY .

Corrections de bugs

  • IndexError sur les requêtes GROUP BY avec paramètres %% échappés et paramètres réels : auparavant, toute requête contenant une clause GROUP BY passait par une étape de réécriture par espace réservé qui correspondait à %\w+ et la remplaçait par {}. Ce régex correspondait aussi aux littéraux %% échappés, qui injectaient des réserveurs fantômes et s’affichaient IndexError: Replacement index N out of range chaque fois qu’une requête combinait un %%-escape avec un paramètre %s réel. L’expression régulière restreinte ne s’applique désormais qu’à %% (conservé tel quel) et à %s (le véritable espace réservé), qui est le seul motif que le compilateur n’émette jamais. La même correction empêche également un bug silencieux sans rapport, où un motif non échappé tel que LIKE '%abc%' dans une requête sans paramètre a été réécrit en LIKE '{}%' et a renvoyé les mauvaises lignes.
  • NotImplementedError pour IntegerChoices dans les requêtes brutes GROUP BY : Auparavant, passer une valeur IntegerChoices à une requête brute contenant une clause GROUP BY provoquait NotImplementedError: Not supported type <enum ...>. L’utilitaire de typage des paramètres utilisait des vérifications strictes du type exact (typ == int), et type(IntegerChoices_value) est la classe d’énumération plutôt que int, donc la valeur a donc déclenché l’exception bien qu’elle soit une sous-classe de int. Les vérifications de type utilisent isinstancedésormais , et la bool branche est évaluée avant la int branche (car bool elle est elle-même une int sous-classe). Les choix d’énumération se lient désormais correctement, bool se lie toujours à BIT, et le simple int reste inchangé.

Version 1.7.3

Date de publication : juin 2026

La version 1.7.3 est une version corrective rétrocompatible comprenant deux correctifs liés à la connexion et à l’exécution.

Corrections de bugs

  • FA001 pour Authentication= les modes autres que ActiveDirectoryMsi: Précédemment, le back-end a ignoré Trusted_Connection=yes uniquement pour ActiveDirectoryMsi. D’autres modes Entra qui ne fournissent pas de valeur USER (par exemple, ActiveDirectoryIntegrated, ActiveDirectoryDefault, ActiveDirectoryDeviceFlow) recevaient quand même Trusted_Connection=yes, que le pilote ODBC a rejetée avec l’erreur FA001 (Cannot use Authentication option with Integrated Security option). Le correctif détecte toute valeur explicite Authentication= au moyen d’une correspondance insensible à la casse et tenant compte des limites de mot, et ignore à la fois Trusted_Connection et Integrated Security=SSPI. La gestion des mots de passe n’est pas modifiée : SqlPassword, ActiveDirectoryPasswordet ActiveDirectoryServicePrincipal continue à envoyer PWD, tout en ActiveDirectoryInteractive continuant à l’omettre.
  • KeyError dans les sous-classes de DatabaseWrapper : les propriétés mises en cache sql_server_version et to_azure_sql_db reposaient sur type(self).__dict__ l’introspection de cached_property, ce qui provoquait KeyError la première fois qu’une sous-classe de DatabaseWrapper y accédait (une régression introduite dans la version 1.7.1). Le correctif utilise des dictionnaires explicites au niveau de la classe (_known_versions, _known_azures), accessibles via self., de sorte que la recherche est résolue selon le MRO et que les wrappers dérivés fonctionnent correctement.

Version 1.7.2

Date de publication : mai 2026

La version 1.7.2 est une version corrective rétrocompatible comprenant des correctifs liés aux fuseaux horaires et à la compatibilité.

Corrections de bugs

  • .explain() Compatibilité avec Django 4.0 et versions ultérieures : correction de la gestion par le compilateur des métadonnées EXPLAIN de Django, de sorte que .explain() n’échoue plus avec AttributeError sous Django 4.0 et versions ultérieures. Le back-end suit désormais les champs d’explication appropriés à la version et déclenche NotSupportedError correctement le cas échéant.
  • gestion des fuseaux horaires de datetimeoffset : correction de l’analyse de datetimeoffset afin que les décalages horaires soient conservés au lieu d’être supprimés. Les valeurs de date et d’heure renvoyées incluent désormais les informations de fuseau horaire lorsque cela est prévu.
  • Now() avec USE_TZ=True : Mise à jour de la génération SQL pour Now() afin d’utiliser un comportement tenant compte du fuseau horaire lorsque la gestion des fuseaux horaires est activée, évitant la dérive des horodatages sur les hôtes SQL Server non UTC.

Version 1.7.1

Date de publication : avril 2026

La version 1.7.1 est une version de correctif rétrocompatible avec des correctifs de bogues.

Corrections de bugs

  • FieldDoesNotExist lors de la modification de champs avec un ordre décroissant des index : correction de _alter_field() dans schema.py pour utiliser index.fields_orders au lieu de index.fields lors de la résolution des noms de champs d’index. Le code précédent transmettait des chaînes brutes de type champ-avec-tri (par exemple, "-pub_date") à model._meta.get_field(), ce qui provoquait FieldDoesNotExist. À présent, seul le nom du champ est extrait et le suffixe de classement est correctement ignoré.
  • Prise en charge de la base de données SQL dans Microsoft Fabric (EngineEdition 12) : Reconnaissance de la base de données SQL dans Fabric (EngineEdition=12) comme une édition Azure. Auparavant, l’édition du moteur de Fabric n’était pas reconnue, ce qui faisait que to_azure_sql_db renvoyait False et que les vérifications de contrôle d’accès aux fonctionnalités échouaient. Le correctif ajoute EDITION_AZURE_SQL_FABRIC=12 à _AZURE_EDITIONS et associe Fabric à la dernière version de SQL Server prise en charge. JSONField, les fonctions de hachage, l’introspection de la collation et le démantèlement de la base de données de test fonctionnent désormais correctement sur Fabric.

Version 1.7

Date de publication : mars 2026

Points forts

  • Prise en charge de Django 6.0 : Compatibilité complète avec Django 6.0, ce qui nécessite Python 3.12 ou version ultérieure. Toutes les modifications d’API 6.0 sont gérées de manière transparente par le serveur principal.
  • Prise en charge partielle CompositePrimaryKey: le back-end ajoute une prise en charge partielle de Django 5.2 CompositePrimaryKey. La comparaison de tuples avec des sous-requêtes nécessite Django 5.2.4 ou ultérieure, et certains cas limites liés aux clés composites et à JSONField subsistent. Django 5.2 a été pris en charge pour la première fois dans mssql-django 1.6.
  • Prise en charge de SQL Server 2025 : Validé avec SQL Server 2025.
  • Pilote ODBC 18 par défaut : le back-end utilise désormais par défaut ODBC Driver 18 for SQL Server, avec un basculement automatique vers ODBC Driver 17 si la version 18 n’est pas installée.

Notes spécifiques à la version

Version de Django Remarques
Django 5.1 inspectdb peut inspecter des tables avec des clés primaires composites, mais elle ne génère pas de définitions de modèle complètes pour celles-ci.
Django 5.2 CompositePrimaryKey la prise en charge est partielle. La comparaison de tuples avec des sous-requêtes nécessite Django 5.2.4 ou une version ultérieure, et certains cas liés aux migrations ainsi que JSONField certains cas limites subsistent.
Django 6.0 Nécessite Python 3.12 ou version ultérieure. Toutes les limitations 5.2 s’appliquent.

Version 1.6

Date de publication : août 2025

  • Ajout de la prise en charge de Django 5.1 et 5.2.
  • Fonctionnalités JSON améliorées et compatibilité descendante.
  • Infrastructure de pipeline améliorée.

Version 1.5

Date de publication : avril 2024

  • Ajout de l’indicateur de fonctionnalité supports_comments pour db_comments.
  • Corrections de bugs pour AutoField, la mise en forme des paramètres et les requêtes de schéma.

Version 1.4

Date de publication : janvier 2024

  • Ajout de la prise en charge de Django 5.0.
  • Ajout de la prise en charge db_comment.
  • Correctifs de bogues pour les conversions de date/heure et les agrégats vides.

Version : 1.3

Date de publication : mai 2023

  • Ajout de la prise en charge de Django 4.2.
  • Ajout de la prise en charge des fonctions Replace sensibles à la casse.
  • Correctifs de bugs concernant la gestion d'OFFSET et le remplissage à gauche.

Version : 1.2

Date de publication : décembre 2022

  • Ajout de la prise en charge de Django 4.1.
  • Ajout de la prise en charge du fuseau horaire (datetimeoffset avec USE_TZ=True).
  • Ajout de l’option return_rows_bulk_insert pour la récupération des ID lors des insertions en bloc.
  • Ajout de la prise en charge de SQL Server 2022.
  • Ajout de la prise en charge JSONField pour Azure SQL Managed Instance.

Version 1.1

Date de publication : juillet 2022

  • Prise en charge de Django 3.2 et 4.0.
  • Prise en charge de SQL Server 2016 et versions ultérieures, ainsi que d’Azure SQL Database.
  • connectivité basée sur pyodbc.

Contenu connexe

  • Last updated on