Co nowego w mssql-django

W tym artykule opisano nowe funkcje, ulepszenia i zmiany w każdej wersji zaplecza mssql-django bazy danych Django.

Wersja 2.0

Data premiery: wrzesień 2026

Wersja 2.0 dodaje sterownik firmy Microsoft mssql-python jako alternatywę dla pyodbc na poziomie poszczególnych baz danych, aktualizuje macierz obsługiwanych wersji Pythona, Django i SQL Servera oraz zawiera poprawki dotyczące zgodności i niezawodności. pyodbc pozostaje domyślnym sterownikiem.

Najważniejsze informacje

• Obsługa sterownika mssql-python: Alias bazy danych jest włączany za pomocą "python_driver": "mssql_python" w jego słowniku OPTIONS. Sterownik obejmuje połączenia, pulowanie połączeń, ponawianie prób, transakcje i punkty przywracania, wartości datetimeoffset, introspekcję oraz uwierzytelnianie Microsoft Entra. Aliasy, które pomijają tę opcję, nadal używają pyodbc, więc nic się nie zmieni, dopóki się na to nie zdecydujesz. Więcej informacji można znaleźć w artykule Wybierz sterownik bazy danych dla mssql-django.
• Brak osobnej instalacji sterownika ODBC na ścieżce mssql-python: alias on mssql-python nie wymaga zewnętrznego zainstalowanego sterownika Microsoft ODBC dla SQL Server. Aliasy, które pozostają na pyodbc, nadal tam pozostają.
• Zmodernizowana macierz wsparcia: Python 3.10 do 3.14, Django 5.2 do 6.1 oraz SQL Server 2017 do 2025. Django 6.0 i nowsze wersje wymagają Python 3.12 lub nowszych.

Poprawki błędów

• Jawnie określone ustawienia MARS są respektowane: jawnie określona wartość MARS_Connection w extra_params jest zachowywana zamiast zostać zastąpiona domyślną wartością systemu Windows, a dopasowanie nie uwzględnia wielkości liter. Ustawienie MARS_Connection=no teraz działa przeciwko endpointom odrzucającym MARS, w tym Microsoft Fabric Warehouse. Po wyłączeniu MARS, ORM buforuje wyniki iteracji przed ich wytworzeniem, aby zagnieżdżone zapytanie mogło ponownie wykorzystać połączenie, co kosztuje więcej pamięci na dużych zestawach zapytań. Ta poprawka połączenia nie dodaje pełnego wsparcia dla migracji w Warehouse ani innych funkcji SQL Server.
• Symbole wieloznaczne ujęte w nawiasy są znakowane znakiem ucieczki w wyszukiwaniach opartych na wyrażeniach: Wyszukiwania wzorców, które porównują dwa pola za pomocą wyrażenia F(), takie jak contains i startswith, powodują poprzedzenie symbolu wieloznacznego [ w SQL Server znakiem ucieczki. Znaki nawiasów są dopasowywane jako dane, a nie jako składnia symboli wieloznacznych.
• Apostrofy w nazwach schematów inspectdb są poprzedzane znakiem ucieczki: Apostrof w wartości inspectdb --schema jest poprzedzany znakiem ucieczki w zapytaniu o metadane, więc nazwy schematów zawierające apostrof nie generują już nieprawidłowych instrukcji Transact-SQL (T-SQL).
• Pusty HOST łączy się z localhost w przypadku ścieżki mssql-python: Pominięty HOST, który Django uzupełnia pustym ciągiem znaków, jest interpretowany jako localhost zamiast powodować błąd walidacji przy pustej wartości SERVER=. To zachowanie odpowiada domyślnemu pyodbc dla lokalnych instancji.

Improvements

• pytz zastąpiony przez zoneinfo i tzdata: obsługa stref czasowych wykorzystuje standardowy moduł bibliotekizoneinfo, a pakiet tzdata dostarcza bazę danych stref czasowych IANA w środowiskach, które jej nie udostępniają, takich jak Windows i minimalne obrazy kontenerów. Przesunięcia są prawidłowe przez cały rok w strefach z ujemnym przesunięciem czasu letniego. pytz nie jest już zależnością.
• Nowsze wersje SQL Server są akceptowane: główna wersja SQL Server, której backend nie rozpoznaje, używa najnowszego zestawu możliwości, o którym backend wie, zamiast nie przechodzić weryfikacji wersji. Możesz połączyć się z nową wersją SQL Server, zanim zostanie wydana odpowiadająca jej wersja mssql-django. Zaakceptowanie połączenia nie oznacza, że nieprzetestowane funkcje są obsługiwane.

Zmiany przełomowe

• Python 3.8 i 3.9 oraz Django 3.2 do 5.1 nie są już wspierane. Kod kompatybilności dla wcześniejszych wersji pozostaje niezmienny, ale te kombinacje nie są testowane ani wymienione.
• mssql-python 1.15.0 lub nowsza jest wymaganą zależnością nawet wtedy, gdy alias używa pyodbc. Instalacja jest ograniczona do platform posiadających kompatybilną dystrybucję mssql-python , co wyklucza SUSE Linux na ARM64. Projekty na innych platformach pozostają na wersji 1.8.0.
• Deklarowane wsparcie dla SQL Server zaczyna się od SQL Server 2017, a deklarowane natywne wsparcie łączności ogranicza się do sterownika Microsoft ODBC 17 oraz sterownika Microsoft ODBC 18.

Wersja 1.8.0

Data premiery: sierpień 2026

Wersja 1.8.0 dodaje wsparcie dla Django 6.1, jednocześnie utrzymując wsparcie dla Django 3.2 do 6.0. Przeniesienie projektu z Django 6.0 do 6.1 nie wymaga żadnych zmian w kodzie, chyba że korzystasz z jednej z dwóch funkcji Django 6.1 opisanych w tej sekcji.

Najważniejsze informacje

• Wsparcie dla Django 6.1: Zweryfikowane przeciwko Django 6.1, kontynuując wsparcie dla Django 3.2 do 6.0. Ograniczenie zależności rozszerza się z django>=3.2,<6.1 do .django>=3.2,<6.2
• Kompilator zapytań używa quote_name w Django 6.1: w Django 6.1 element quote_name_unless_alias jest uznawany za przestarzały. Backend wywołuje teraz SQLCompiler.quote_name w Django 6.1 i nowszych wersjach, zależnie od wersji, dzięki czemu wcześniejsze wersje Django pozostają bez zmian. Zapytania dzielone i z przesunięciem, takie jak qs[a:b] i OFFSET ... FETCH, są kompilowane bez ostrzeżeń o przestarzałości.
• Introspekcja klucza obcego zwraca regułę ON DELETE: w Django 6.1 rozszerzono get_relations() tak, aby uwzględniało regułę ON DELETE na poziomie bazy danych. Backend zwraca oczekiwaną strukturę trójczęściową i odpowiednio mapuje klucze obce SQL Server NO ACTION, dzięki czemu inspectdb oraz introspekcja kluczy obcych generują poprawne modele.

Funkcje Django 6.1, które nie są obsługiwane

Dwa dodatki do Django 6.1 są niedostępne na tym backendzie, z różnych powodów:

• Działania referencyjne na poziomie bazy danych (DB_CASCADE, DB_SET_NULL, ): DB_SET_DEFAULTSQL Server odrzuca obce grafy kluczy z wieloma ścieżkami kaskadowymi prowadzącymi do tej samej tabeli (błąd 1785), więc nie ma natywnej ścieżki dla tej funkcji w żadnej wersji SQL Server. Użycie jednej z tych wartości wywołuje kontrolę systemową Django fields.E324, która wskazuje na standardową wartość na poziomie Django on_delete.
• Agregaty bitowe (BitAnd, BitOr, ): BitXorSQL Server nie posiada natywnej funkcji agregacji bitowej, a backend ich nie emuluje, więc agregaty te generują NotSupportedError.

Aby uzyskać więcej informacji, zobacz Ograniczenia i nieobsługiwane funkcje w programie mssql-django.

Wersja 1.7.4

Data premiery: lipiec 2026

Wersja 1.7.4 to wydanie poprawkowe zachowujące zgodność wsteczną, zawierające dwie poprawki dotyczące obsługi zapytań raw i annotated GROUP BY.

Poprawki błędów

• IndexError w zapytaniach GROUP BY z parametrami escaped %% i rzeczywistymi: Wcześniej każde zapytanie z klauzulą GROUP BY przechodziło przez krok przepisywania zastępców, który dopasowywał %\w+ i zastępował je przez {}. To wyrażenie regularne dopasowywało również literały z sekwencją ucieczki %%, co wstawiało pozorne symbole zastępcze i powodowało wystąpienie IndexError: Replacement index N out of range, gdy zapytanie łączyło sekwencję ucieczki %% z rzeczywistym parametrem %s. Zwężony regex teraz obejmuje tylko %% (zachowany dosłownie) oraz %s (rzeczywisty symbol zastępczy), który jest jedynym wzorcem, jaki kompilator kiedykolwiek generuje. Ta sama poprawka zapobiega również niepowiązanemu cichemu błędowi, w którym nieeskapowany wzorzec, taki jak LIKE '%abc%', w zapytaniu bez parametrów był przepisywany na LIKE '{}%', przez co zwracane były nieprawidłowe wiersze.
• NotImplementedError dla IntegerChoices w surowych GROUP BY zapytaniach: Wcześniej przekazanie wartości IntegerChoices do surowego zapytania, które zawierało klauzulę GROUP BY, wywoływało NotImplementedError: Not supported type <enum ...>. Pomocnik typowania parametrów używał dokładnych sprawdzeń typu (typ == int), a type(IntegerChoices_value) jest klasą wyliczeniową, a nie int, więc wartość trafiała do zgłoszenia wyjątku, mimo że jest podklasą int. Sprawdzanie typów teraz używa isinstance, a gałąź bool jest oceniana przed gałęzią int (ponieważ bool sama jest podklasą int ). Wartości wyliczeniowe są teraz poprawnie wiązane, bool nadal wiąże BIT, a zwykłe wiązanie int pozostaje bez zmian.

Wersja 1.7.3

Data wydania: czerwiec 2026 r.

Wersja 1.7.3 to zgodne wstecznie wydanie poprawkowe zawierające dwie poprawki dotyczące połączeń i środowiska uruchomieniowego.

Poprawki błędów

• FA001 dla Authentication= trybów innych niż ActiveDirectoryMsi: Wcześniej zaplecze pominąło Trusted_Connection=yes tylko dla ActiveDirectoryMsi. Inne tryby Entra, które nie podają wartości USER (na przykład ActiveDirectoryIntegrated, ActiveDirectoryDefault, ActiveDirectoryDeviceFlow), nadal otrzymały Trusted_Connection=yes, którą sterownik ODBC odrzucił za pomocą FA001 (Cannot use Authentication option with Integrated Security option). Poprawka wykrywa dowolną jawną wartość Authentication= za pomocą dopasowania uwzględniającego granice wyrazów i bez rozróżniania wielkości liter oraz pomija zarówno Trusted_Connection, jak i Integrated Security=SSPI. Obsługa haseł pozostaje bez zmian: SqlPassword, ActiveDirectoryPassword i ActiveDirectoryServicePrincipal nadal wysyłają PWD, natomiast ActiveDirectoryInteractive nadal je pomija.
• KeyError w podklasach DatabaseWrapper: buforowane właściwości sql_server_version i to_azure_sql_db opierały się na introspekcji type(self).__dict__cached_property, co powodowało zgłoszenie KeyError przy pierwszym dostępie do nich przez podklasę DatabaseWrapper (regresja wprowadzona w wersji 1.7.1). Poprawka używa jawnych słowników na poziomie klasy (_known_versions, _known_azures), uzyskiwanych za pośrednictwem self., dzięki czemu odwołanie jest rozstrzygane zgodnie z MRO, a opakowania dziedziczące działają poprawnie.

Wersja 1.7.2

Data wydania: maj 2026 r.

Wersja 1.7.2 to wstecznie kompatybilne wydanie poprawkowe z poprawkami dotyczącymi stref czasowych i zgodności.

Poprawki błędów

• .explain() zgodność z Django 4.0 i nowszymi wersjami: Naprawiono obsługę metadanych `explain` w Django przez kompilator, dzięki czemu .explain() nie kończy się już błędem AttributeError w Django 4.0 i nowszych wersjach. Backend obsługuje teraz pola explain odpowiednie dla danej wersji i w razie potrzeby poprawnie zgłasza NotSupportedError.
• obsługa strefy czasowej datetimeoffset: Naprawiono analizowanie elementu datetimeoffset, tak aby zachować przesunięcia strefy czasowej zamiast je odrzucać. Zwracane wartości daty i godziny zawierają teraz informację o strefie czasowej tam, gdzie jest to oczekiwane.
• Now() with USE_TZ=True: Zaktualizowano generowanie kodu SQL dla Now(), aby używało mechanizmu uwzględniającego strefę czasową, gdy obsługa stref czasowych jest włączona, co zapobiega przesunięciom znaczników czasu na hostach SQL Server, które nie używają strefy UTC.

Wersja 1.7.1

Data wydania: kwiecień 2026 r.

Wersja 1.7.1 to wydanie poprawkowe zachowujące zgodność wsteczną i zawierające poprawki błędów.

Poprawki błędów

• FieldDoesNotExist podczas zmiany pól z malejącą kolejnością indeksów: Naprawiono _alter_field() w poleceniu schema.py, aby do rozpoznawania nazw pól indeksu używać index.fields_orders zamiast index.fields. Poprzedni kod przekazywał do "-pub_date" surowe ciągi określające pola wraz z kolejnością sortowania (na przykład model._meta.get_field()), co powodowało zgłoszenie wyjątku FieldDoesNotExist. Teraz wyodrębniana jest tylko nazwa pola, a sufiks sortowania jest poprawnie usuwany.
• Obsługa bazy danych SQL w usłudze Microsoft Fabric (EngineEdition 12): Rozpoznano bazę danych SQL w usłudze Fabric (EngineEdition=12) jako wersję platformy Azure. Wcześniej edycja silnika Fabric nie była rozpoznawana, co powodowało, że to_azure_sql_db zwracało False, a sprawdzenia bramkowania funkcji kończyły się niepowodzeniem. Poprawka dodaje EDITION_AZURE_SQL_FABRIC=12 do _AZURE_EDITIONS i mapuje usługę Fabric na najnowszą obsługiwaną wersję programu SQL Server. JSONField, funkcje skrótu, inspekcja reguł sortowania oraz usuwanie testowej bazy danych działają teraz poprawnie w środowisku Fabric.

Wersja 1.7

Data wydania: marzec 2026 r.

Najważniejsze informacje

• Obsługa platformy Django 6.0: pełna zgodność z wersją Django 6.0, która wymaga Python 3.12 lub nowszej. Wszystkie zmiany w API 6.0 są transparentnie obsługiwane przez backend.
• Częściowe CompositePrimaryKey wsparcie: Backend dodaje częściowe wsparcie dla Django 5.2 CompositePrimaryKey. Porównywanie krotek z podzapytaniami wymaga Django 5.2.4 lub nowszego, a niektóre przypadki brzegowe związane z kluczami złożonymi i JSONField pozostają nierozwiązane. Sam Django 5.2 został po raz pierwszy obsługiwany w mssql-django 1.6.
• Obsługa SQL Server 2025: Zweryfikowano pod kątem zgodności z SQL Server 2025.
• Domyślny sterownik ODBC 18: zaplecze teraz domyślnie używa sterownika ODBC 18 dla SQL Server z automatycznym powrotem do sterownika ODBC 17, jeśli wersja 18 nie jest zainstalowana.

Uwagi dotyczące wersji

Wersja 1.6

Data wydania: sierpień 2025 r.

• Dodano obsługę platformy Django 5.1 i 5.2.
• Ulepszona funkcjonalność JSON i zgodność z poprzednimi wersjami.
• Ulepszona infrastruktura potoku.

Wersja 1.5

Data wydania: kwiecień 2024 r.

• Dodano flagę funkcji supports_comments dla db_comments.
• Poprawki dla AutoField, formatowania parametrów i zapytań schematu.

Wersja 1.4

Data wydania: styczeń 2024 r.

• Dodano obsługę platformy Django 5.0.
• Dodano obsługę db_comment.
• Poprawki błędów dotyczące konwersji daty/godziny i pustych agregacji.

Wersja 1.3

Data wydania: maj 2023 r.

• Dodano obsługę platformy Django 4.2.
• Dodano obsługę funkcji uwzględniającej wielkość Replace liter.
• Poprawki błędów dotyczące obsługi OFFSET i dopełnienia z lewej strony.

Wersja 1.2

Data wydania: grudzień 2022 r.

• Dodano obsługę platformy Django 4.1.
• Dodano obsługę strefy czasowej (datetimeoffset z funkcją USE_TZ=True).
• Dodano opcję return_rows_bulk_insert pobierania identyfikatora przy wstawianiu zbiorczym.
• Dodano obsługę SQL Server 2022.
• Dodano JSONField obsługę usługi Azure SQL Managed Instance.

Wersja 1.1

Data wydania: lipiec 2022 r.

• Obsługa platformY Django 3.2 i 4.0.
• Programy SQL Server 2016 i nowsze oraz Azure SQL Database są obsługiwane.
• łączność oparta na pyodbc

Treści powiązane

• Instalowanie narzędzia mssql-django
• Wybierz sterownik bazy danych dla mssql-django
• pomoc techniczna i cykl życia bazy danych mssql-django
• Ograniczenia i nieobsługiwane funkcje w narzędziu mssql-django
• wydania mssql-django w serwisie GitHub