1.4 Changelog

Dieses Dokument beschreibt individuelle Änderungen auf Issue-Ebene, die während der Veröffentlichungen von 1.4 vorgenommen wurden. Für einen narrativen Überblick über die Neuerungen in 1.4 siehe Was ist neu in SQLAlchemy 1.4?.

1.4.55

kein Veröffentlichungsdatum

1.4.54

Veröffentlicht: 5. September 2024

allgemein

• [allgemein] [änderung]

  Die Einschränkung für setuptools<69.3 in pyproject.toml wurde entfernt. Diese Einschränkung diente dazu, eine plötzliche Änderung in setuptools zu verhindern, die den Dateinamen der SQLAlchemy-Quellcode-Distribution auf PyPI in Kleinbuchstaben geändert hätte, was wahrscheinlich zu Problemen mit verschiedenen Build-Umgebungen geführt hätte, die den bisherigen Benennungsstil erwarteten. Die Anwesenheit dieser Einschränkung hindert jedoch Umgebungen, die neuere setuptools verwenden möchten, daran, so haben wir uns entschieden, diesen Schritt zu gehen, mit der Annahme, dass Build-Umgebungen die setuptools-Änderung inzwischen weitgehend übernommen haben.

  Diese Änderung wurde zuerst in Version 2.0.33 veröffentlicht, wird aber nach 1.4.54 zurückportiert, um fortlaufende Veröffentlichungen zu unterstützen.

  Referenzen: #11818

• [allgemein] [änderung]

  Der setuptools "test"-Befehl wurde aus der 1.4-Serie entfernt, da moderne Versionen von setuptools aktiv darauf verzichten, diese Erweiterung zuzulassen. Diese Änderung war bereits Teil der 2.0-Serie. Um die Testsuite auszuführen, verwenden Sie den tox Befehl.

orm

• [orm] [fehler] [regression]

  Behobene Regression aus 1.3, bei der der Spaltenschlüssel, der für eine Hybrid-Eigenschaft verwendet wurde, mit dem des zugrunde liegenden Spaltens gefüllt werden könnte, den sie zurückgibt, für eine Eigenschaft, die direkt eine ORM-zugeordnete Spalte zurückgibt, anstatt des Schlüssels, der von der Hybrid-Eigenschaft selbst verwendet wird.

  Referenzen: #11728

postgresql

• [postgresql] [fehler]

  Kritischer Fehler im asyncpg-Treiber behoben, bei dem ein Rollback oder Commit, der speziell für die Bedingung MissingGreenlet oder einen anderen Fehler, der nicht von asyncpg selbst ausgelöst wurde, fehlschlug, die asyncpg-Transaktion in jedem Fall verwarf, obwohl die Transaktion noch inaktiv war, was zu einem serverseitigen Zustand mit einer inaktiven Transaktion führte, die dann wieder in den Connection-Pool zurückkehrte. Die Flags für "Transaktion geschlossen" werden nun nicht mehr für Fehler zurückgesetzt, die außerhalb von asyncpg selbst auftreten. Wenn asyncpg selbst einen Fehler für .commit() oder .rollback() auslöst, verwirft asyncpg diese Transaktion dann.

  Referenzen: #11819

1.4.53

Veröffentlicht: 29. Juli 2024

allgemein

• [allgemein] [fehler]

  Vollständige Unterstützung für Python 3.13 eingerichtet, soweit derzeit möglich, wobei Probleme in internen Sprachhelfern sowie im Serializer-Erweiterungsmodul behoben wurden.

  Für die Version 1.4 werden auch die Namen der "Extras" in setup.cfg modernisiert, um Bindestriche anstelle von Unterstrichen für zweigliedrige Namen zu verwenden. Unterstrichnamen sind weiterhin vorhanden, um potenzielle Kompatibilitätsprobleme zu berücksichtigen.

  Referenzen: #11417

orm

• [orm] [fehler] [regression]

  Behobene Regression, die bis zu 1.4 zurückreicht, bei der der Zugriff auf eine Sammlung mit der "dynamischen" Strategie auf einem transienten Objekt und der Versuch einer Abfrage einen internen Fehler auslöste, anstatt des erwarteten NoResultFound, der in 1.3 auftrat.

  Referenzen: #11562

engine

• [engine] [anwendungsfall]

  Die interne Darstellung für die Anpassung von asyncio-Aufrufen an Greenlets wurde geändert, um eine Duck-Typing-Kompatibilität mit Drittanbieterbibliotheken zu ermöglichen, die SQLAlchemy's "Greenlet-to-Asyncio"-Muster direkt implementieren. Das Ausführen von Code innerhalb eines Greenlets, das das Attribut __sqlalchemy_greenlet_provider__ = True aufweist, ermöglicht direkte Aufrufe von sqlalchemy.util.await_only().

• [engine] [fehler]

  Anpassungen an den C-Erweiterungen, die spezifisch für die SQLAlchemy 1.x-Serie sind, um unter Python 3.13 zu funktionieren. Pull Request von Ben Beasley.

  Referenzen: #11499

sql

• [sql] [fehler]

  Behobenes Caching-Problem, bei dem die Verwendung der Methode TextualSelect.add_cte() des Konstrukts TextualSelect keinen korrekten Cache-Schlüssel festlegte, der zwischen verschiedenen CTE-Ausdrücken unterschied.

  Referenzen: #11471

• [sql] [fehler]

  Behobenes Caching-Problem, bei dem das Element Select.with_for_update.key_share von Select.with_for_update() nicht als Teil des Cache-Schlüssels berücksichtigt wurde, was zu falschem Caching führte, wenn verschiedene Variationen dieses Parameters mit einer ansonsten identischen Anweisung verwendet wurden.

  Referenzen: #11544

mypy

• [mypy] [fehler]

  Das veraltete mypy-Plugin ist mit der neuesten Version von mypy 1.11.0 nicht mehr voll funktionsfähig, da Änderungen im mypy-Interpreter nicht mehr mit dem vom Plugin verwendeten Ansatz kompatibel sind. Wenn Code von dem mypy-Plugin mit sqlalchemy2-stubs abhängig ist, wird empfohlen, mypy auf eine Version unterhalb der 1.11.0-Serie zu beschränken. Erwägen Sie ein Upgrade auf die 2.0-Serie von SQLAlchemy und die Migration zu modernen Typannotationen.

  Siehe auch

  Mypy / Pep-484 Unterstützung für ORM-Mappings

sqlite

• [sqlite] [fehler] [reflection]

  Behobene Reflexion von berechneten Spalten in SQLite, um komplexe Ausdrücke ordnungsgemäß zu berücksichtigen.

  Referenzen: #11582

mssql

• [mssql] [fehler]

  Problem behoben, bei dem SQL Server-Treiber keine gebundenen Parameter unterstützen, wenn die "Frame-Spezifikation" für eine Fensterfunktion gerendert wird, z. B. "ROWS BETWEEN", usw.

  Referenzen: #11514

1.4.52

Veröffentlicht: 4. März 2024

orm

• [orm] [fehler]

  Fehler behoben, bei dem ORM with_loader_criteria() nicht auf eine Select.join() angewendet wurde, bei der die ON-Klausel als einfacher SQL-Vergleich und nicht als Beziehungsziel oder ähnliches angegeben wurde.

  Dies ist ein Backport desselben Problems, das in Version 2.0 für 2.0.22 behoben wurde.

  Update – dies hat auch ein Problem behoben, bei dem Kriterien für Einzelvererbung nicht korrekt auf eine Unterklassen-Entität angewendet wurden, die nur in der select_from() Liste erschien, siehe #11412

  Referenzen: #10365, #11412

1.4.51

Veröffentlicht: 2. Januar 2024

orm

• [orm] [fehler]

  Verbesserte Korrektur, die erstmals für #3208 in Version 0.9.8 implementiert wurde, bei der das von deklarierten Klassen intern verwendete Klassenregister einem Race Condition ausgesetzt sein konnte, wenn einzelne zugeordnete Klassen gleichzeitig gelöscht wurden, während neue zugeordnete Klassen konstruiert wurden, wie es in einigen Testsuite-Konfigurationen oder dynamischen Klassenerstellungsumgebungen vorkommen kann. Zusätzlich zur bereits hinzugefügten Weakref-Prüfung wird nun auch die Liste der durchlaufenen Elemente zuerst kopiert, um "Liste während der Iteration geändert"-Fehler zu vermeiden. Pull Request von Yilei Yang.

  Referenzen: #10782

asyncio

• [asyncio] [fehler]

  Kritischer Fehler in der asyncio-Version des Connection-Pools behoben: Der Aufruf von AsyncEngine.dispose() erzeugte einen neuen Connection-Pool, der die Verwendung von asyncio-kompatiblen Mutexes nicht vollständig wiederherstellte, was zur Verwendung eines einfachen threading.Lock() führte. Dies verursachte dann Deadlocks in einem asyncio-Kontext bei der Verwendung von Nebenläufigkeitsfunktionen wie asyncio.gather().

  Referenzen: #10813

mysql

• [mysql] [fehler]

  Behobene Regression, die durch die Korrektur in Ticket #10492 beim Verwenden von Pool-Pre-Ping mit PyMySQL-Versionen älter als 1.0 eingeführt wurde.

  Referenzen: #10650

1.4.50

Veröffentlicht: 29. Oktober 2023

orm

• [orm] [fehler]

  Behobenes grundlegendes Problem, das einige Formen von ORM-"Annotationen" für Unterabfragen verhinderte, die Select.join() gegen ein Beziehungsziel verwendeten. Diese Annotationen werden verwendet, wenn eine Unterabfrage in speziellen Situationen wie innerhalb von PropComparator.and_() und anderen ORM-spezifischen Szenarien verwendet wird.

  Referenzen: #10223

sql

• [sql] [fehler]

  Problem behoben, bei dem die Verwendung desselben gebundenen Parameters mehr als einmal mit literal_execute=True in einigen Kombinationen mit anderen Literal-Rendering-Parametern die falschen Werte gerendert hätte, aufgrund eines Iterationsproblems.

  Referenzen: #10142

• [sql] [fehler]

  Problem behoben, bei dem das Entpickeln einer Column oder eines anderen ColumnElement das korrekte "Comparator"-Objekt nicht wiederherstellte, das zum Erzeugen von SQL-Ausdrücken verwendet wird, die spezifisch für das Typobjekt sind.

  Referenzen: #10213

schema

• [schema] [fehler]

  Die Darstellung des nur für Oracle gültigen Parameters Identity.order, der Teil von sowohl Sequence als auch Identity ist, wurde geändert, sodass sie nur für das Oracle-Backend und nicht für andere Backends wie PostgreSQL stattfindet. Eine zukünftige Version wird die Parameter Identity.order, Sequence.order und Identity.on_null in Oracle-spezifische Namen umbenennen und die alten Namen deprecaten. Diese Parameter gelten nur für Oracle.

  Referenzen: #10207

mysql

• [mysql] [anwendungsfall]

  Aktualisierte aiomysql-Dialekt, da der Dialekt wieder gepflegt zu werden scheint. Wieder in die CI-Tests integriert unter Verwendung der Version 0.2.0.

• [mysql] [fehler]

  Reparatur einer neuen Inkompatibilität im MySQL "Pre-Ping"-Routinen, bei der das an connection.ping() übergebene Argument False, das dazu dient, eine unerwünschte "automatische Wiederverbindung"-Funktion zu deaktivieren, in MySQL-Treibern und Backends deprecated wird und bei einigen Versionen von MySQLs nativen Client-Treibern Warnungen verursacht. Es wurde für mysqlclient entfernt, während es für PyMySQL und auf PyMySQL basierende Treiber zu einem späteren Zeitpunkt deprecated und entfernt wird. Daher wird API-Introspektion verwendet, um zukunftssicher gegen diese verschiedenen Phasen der Entfernung zu sein.

  Referenzen: #10492

mssql

• [mssql] [fehler] [reflection]

  Problem behoben, bei dem die Reflexion von Identitätsspalten für eine BIGINT-Spalte mit einem großen Identitätsstartwert (mehr als 18 Ziffern) fehlschlug.

  Referenzen: #10504

1.4.49

Veröffentlicht: 5. Juli 2023

platform

• [platform] [anwendungsfall]

  Kompatibilitätsverbesserungen, um vollständig mit Python 3.12 zu funktionieren

sql

• [sql] [fehler]

  Problem behoben, bei dem die Verwendung von ColumnOperators.regexp_match() mit "Flags" keinen "stabilen" Cache-Schlüssel erzeugte, d.h. der Cache-Schlüssel änderte sich jedes Mal, was zu Cache-Verschmutzung führte. Das gleiche Problem bestand für ColumnOperators.regexp_replace() sowohl mit den Flags als auch mit dem tatsächlichen Ersetzungsdruck. Die Flags werden nun als feste Modifikatorzeichenketten dargestellt, die als Safestrings gerendert werden, anstatt als gebundene Parameter, und der Ersetzungsdruck wird innerhalb des primären Teils des "binären" Elements etabliert, sodass er einen geeigneten Cache-Schlüssel generiert.

  Beachten Sie, dass im Rahmen dieser Änderung die Parameter ColumnOperators.regexp_match.flags und ColumnOperators.regexp_replace.flags so geändert wurden, dass sie nur als literale Zeichenketten gerendert werden, während sie zuvor als vollständige SQL-Ausdrücke, typischerweise gebundene Parameter, gerendert wurden. Diese Parameter sollten immer als reine Python-Zeichenketten und nicht als SQL-Ausdruckskonstrukte übergeben werden; es wird nicht erwartet, dass SQL-Ausdruckskonstrukte für diesen Parameter in der Praxis verwendet wurden, daher ist dies eine rückwärtsinkompatible Änderung.

  Die Änderung modifiziert auch die interne Struktur des generierten Ausdrucks für ColumnOperators.regexp_replace() mit oder ohne Flags und für ColumnOperators.regexp_match() mit Flags. Drittanbieter-Dialekte, die möglicherweise eigene Regexp-Implementierungen implementiert haben (es konnten keine solchen Dialekte bei einer Suche gefunden werden, daher wird die Auswirkung voraussichtlich gering sein), müssten die Traversierung der Struktur anpassen, um dies zu berücksichtigen.

  Referenzen: #10042

• [sql] [fehler]

  Problem im größtenteils internen Konstrukt CacheKey behoben, bei dem der Operator __ne__() nicht ordnungsgemäß implementiert war, was zu unsinnigen Ergebnissen beim Vergleichen von CacheKey-Instanzen untereinander führte.

extensions

• [extensions] [fehler]

  Problem im mypy-Plugin für die Verwendung mit mypy 1.4 behoben.

1.4.48

Veröffentlicht: 30. April 2023

orm

• [orm] [fehler]

  Kritisches Caching-Problem behoben, bei dem die Kombination von aliased() und hybrid_property()-Ausdruckskompositionen zu einem Cache-Schlüssel-Mismatch führten, was dazu führte, dass Cache-Schlüssel das tatsächliche aliased()-Objekt enthielten, aber nicht mit denen äquivalenter Konstrukte übereinstimmten, wodurch der Cache gefüllt wurde.

  Referenzen: #9728

• [orm] [fehler]

  Fehler behoben, bei dem verschiedene ORM-spezifische Getter wie ORMExecuteState.is_column_load, ORMExecuteState.is_relationship_load, ORMExecuteState.loader_strategy_path etc. einen AttributeError auslösten, wenn die SQL-Anweisung selbst eine "zusammengesetzte Auswahl" wie eine UNION war.

  Referenzen: #9634

• [orm] [fehler]

  Endlosschleife behoben, die auftreten konnte, wenn die Funktion "Beziehung zu alias-Klasse" verwendet wurde und gleichzeitig ein rekursiver Eager-Loader wie lazy="selectinload" im Loader angegeben war, in Kombination mit einem anderen Eager-Loader auf der gegenüberliegenden Seite. Die Prüfung auf Zyklen wurde korrigiert, um auch alias-Klassen-Beziehungen einzuschließen.

  Referenzen: #9590

1.4.47

Veröffentlicht: 18. März 2023

sql

• [sql] [fehler]

  Fehler / Regression behoben, bei der die Verwendung von bindparam() mit demselben Namen wie eine Spalte in der Methode Update.values() von Update, sowie in der Methode Insert.values() von Insert in 2.0 nur, in einigen Fällen dazu führte, dass der SQL-Ausdruck, in dem der Parameter dargestellt wurde, stillschweigend ignoriert wurde, wobei der Ausdruck durch einen neuen Parameter mit demselben Namen ersetzt und alle anderen Elemente des SQL-Ausdrucks, wie z.B. SQL-Funktionen usw., verworfen wurden. Der spezifische Fall wären Anweisungen, die gegen ORM-Entitäten und nicht gegen reine Table-Instanzen konstruiert wurden, aber auch aufgetreten wären, wenn die Anweisung mit einer Session oder einer Connection aufgerufen worden wäre.

  Update ein Teil des Problems war sowohl in 2.0 als auch in 1.4 vorhanden und wird nach 1.4 zurückportiert.

  Referenzen: #9075

• [sql] [fehler]

  Die Stringifizierung für die DDL-Konstrukte CreateSchema und DropSchema wurde behoben, die mit einem AttributeError fehlgeschlagen wäre, wenn sie ohne Dialekt stringifiziert wurden.

  Referenzen: #7664

• [sql] [fehler]

  Kritisches SQL-Caching-Problem behoben, bei dem die Verwendung der benutzerdefinierten Operatorfunktion Operators.op() keinen angemessenen Cache-Schlüssel erzeugte, was zu einer geringeren Effektivität des SQL-Caches führte.

  Referenzen: #9506

mypy

• [mypy] [fehler]

  Anpassungen am mypy-Plugin vorgenommen, um einige potenzielle Änderungen für Issue #236 (sqlalchemy2-stubs) bei Verwendung von SQLAlchemy 1.4 zu berücksichtigen. Diese Änderungen werden innerhalb von SQLAlchemy 2.0 synchron gehalten. Die Änderungen sind auch abwärtskompatibel mit älteren Versionen von sqlalchemy2-stubs.

• [mypy] [fehler]

  Abgestürzt im mypy-Plugin behoben, das sowohl in 1.4- als auch in 2.0-Versionen auftreten konnte, wenn ein Dekorator für den mapped()-Dekorator verwendet wurde, der in einem Ausdruck mit mehr als zwei Komponenten referenziert wurde (z.B. @Backend.mapper_registry.mapped). Dieses Szenario wird nun ignoriert; bei Verwendung des Plugins muss der Dekorator-Ausdruck aus zwei Komponenten bestehen (d.h. @reg.mapped).

  Referenzen: #9102

postgresql

• [postgresql] [fehler]

  Unterstützung für den asyncpg-Dialekt hinzugefügt, um den cursor.rowcount-Wert für SELECT-Anweisungen zurückzugeben, wenn verfügbar. Obwohl dies keine typische Verwendung für cursor.rowcount ist, stellen die anderen PostgreSQL-Dialekte diesen Wert im Allgemeinen zur Verfügung. Pull Request von Michael Gorven.

  Referenzen: #9048

mysql

• [mysql] [anwendungsfall]

  Unterstützung für die MySQL-Indexreflexion hinzugefügt, um das Wörterbuch mysql_length korrekt zu reflektieren, das zuvor ignoriert wurde.

  Referenzen: #9047

mssql

• [mssql] [fehler]

  Fehler behoben, bei dem ein Schema-Name, der mit Klammern, aber ohne Punkte innerhalb des Namens angegeben wurde, für Parameter wie Table.schema, nicht im Kontext des dokumentierten Verhaltens des SQL Server-Dialekts interpretiert wurde, das explizite Klammern als Token-Trennzeichen interpretiert, die erstmals in 1.2 für #2626 hinzugefügt wurden, wenn der Schema-Name in Reflexionsoperationen referenziert wurde. Die ursprüngliche Annahme für das Verhalten von #2626 war, dass die spezielle Interpretation von Klammern nur dann signifikant war, wenn Punkte vorhanden waren. In der Praxis werden die Klammern jedoch nicht als Teil des Bezeichnernamens für alle SQL-Rendering-Operationen einbezogen, da diese keine gültigen Zeichen innerhalb regulärer oder delimitierter Bezeichner sind. Pull Request von Shan.

  Referenzen: #9133

oracle

• [oracle] [fehler]

  Hinzugefügt ROWID zu den reflektierten Typen, da dieser Typ in einer "CREATE TABLE"-Anweisung verwendet werden kann.

  Referenzen: #5047

1.4.46

Veröffentlicht: 3. Januar 2023

allgemein

• [allgemein] [änderung]

  Eine neue Deprecation-Warnung "Uber-Warnung" wird nun beim ersten Auftreten einer SQLAlchemy 2.0 Deprecation-Warnung ausgegeben, wenn die Umgebungsvariable SQLALCHEMY_WARN_20 nicht gesetzt ist. Die Warnung wird höchstens einmal ausgegeben, bevor eine boolesche Variable gesetzt wird, um zu verhindern, dass sie ein zweites Mal ausgegeben wird.

  Diese Deprecation-Warnung soll Benutzer benachrichtigen, die keine geeignete Einschränkung in ihren Requirements-Dateien gesetzt haben, um ein unerwartetes SQLAlchemy 2.0-Upgrade zu verhindern, und sie darauf aufmerksam machen, dass der SQLAlchemy 2.0-Upgrade-Prozess verfügbar ist, da die erste vollständige 2.0-Veröffentlichung sehr bald erwartet wird. Die Deprecation-Warnung kann durch Setzen der Umgebungsvariable SQLALCHEMY_SILENCE_UBER_WARNING auf "1" unterdrückt werden.

  Siehe auch

  SQLAlchemy 2.0 - Major Migration Guide

  Referenzen: #8983

• [allgemein] [bug]

  Behobene Regression, bei der das Basis-Compat-Modul platform.architecture() aufrief, um einige Systemmerkmale zu erkennen, was zu einem übermäßig breiten Systemaufruf gegen den systemweiten file-Aufruf führte, der unter bestimmten Umständen, einschließlich einiger sicherer Umgebungskonfigurationen, nicht verfügbar war.

  Referenzen: #8995

orm

• [orm] [bug]

  Behobenes Problem bei der internen SQL-Traversal für DML-Anweisungen wie Update und Delete, was unter anderem zu einem spezifischen Problem bei der Verwendung von Lambda-Anweisungen mit der ORM Update/Delete-Funktion führen konnte.

  Referenzen: #9033

engine

• [engine] [bug]

  Behobene langjährige Race Condition im Connection Pool, die unter Eventlet/Gevent Monkeypatching-Schemata in Verbindung mit der Verwendung von Eventlet/Gevent Timeout-Bedingungen auftreten konnte, bei der ein Connection Pool Checkout, der aufgrund des Timeouts unterbrochen wurde, den fehlerhaften Zustand nicht bereinigen konnte, was dazu führte, dass der zugrundeliegende Verbindungsdatensatz und manchmal auch die Datenbankverbindung selbst "leckten" und den Pool in einem ungültigen Zustand mit unerreichbaren Einträgen hinterließen. Dieses Problem wurde zuerst in SQLAlchemy 1.2 für #4225 identifiziert und behoben, jedoch konnten die in dieser Korrektur erkannten Fehlerarten BaseException anstelle von Exception nicht berücksichtigen, was verhinderte, dass Eventlet/Gevent Timeout abgefangen wurde. Zusätzlich wurde ein Block im initialen Pool-Connect identifiziert und mit einem BaseException -> "clean failed connect" Block gehärtet, um dieselbe Bedingung an dieser Stelle zu berücksichtigen. Großer Dank an den Github-Benutzer @niklaus für seine hartnäckigen Bemühungen bei der Identifizierung und Beschreibung dieses komplexen Problems.

  Referenzen: #8974

sql

• [sql] [bug]

  Parameter FunctionElement.column_valued.joins_implicitly hinzugefügt, der nützlich ist, um die Warnung vor "kartesischem Produkt" bei der Verwendung von Tabellen- oder Spaltenwertfunktionen zu verhindern. Dieser Parameter wurde bereits für FunctionElement.table_valued() in #7845 eingeführt, jedoch nicht für FunctionElement.column_valued().

  Referenzen: #9009

• [sql] [bug]

  Behobener Fehler, bei dem die SQL-Kompilierung fehlschlug (Assertion-Fehler in 2.0, NoneType-Fehler in 1.4) bei der Verwendung eines Ausdrucks, dessen Typ TypeEngine.bind_expression() enthielt, im Kontext eines "erweiternden" (d. h. "IN") Parameters in Verbindung mit dem Compiler-Parameter literal_binds.

  Referenzen: #8989

• [sql] [bug]

  Behobenes Problem in der Lambda-SQL-Funktion, bei dem der berechnete Typ eines literalen Werts die Typumwandlungsregeln des "verglichenen Typs" nicht berücksichtigte, was zu einem Mangel an Typinformationen für SQL-Ausdrücke führte, wie z. B. Vergleiche mit JSON-Elementen und Ähnlichem.

  Referenzen: #9029

postgresql

• [postgresql] [anwendungsfall]

  PostgreSQL-Typ MACADDR8 hinzugefügt. Pull Request von Asim Farooq.

  Referenzen: #8393

• [postgresql] [bug]

  Behobener Fehler, bei dem der Parameter Insert.on_conflict_do_update.constraint des PostgreSQL-Dialekts ein Index-Objekt akzeptierte, dieses aber nicht in seine einzelnen Indexausdrücke expandierte, sondern stattdessen seinen Namen in einer ON CONFLICT ON CONSTRAINT-Klausel rendert, was von PostgreSQL nicht akzeptiert wird; die Form "constraint name" akzeptiert nur eindeutige oder ausschließende Constraint-Namen. Der Parameter akzeptiert weiterhin den Index, expandiert ihn aber nun in seine Komponenten-Ausdrücke für das Rendering.

  Referenzen: #9023

sqlite

• [sqlite] [bug]

  Behobene Regression, verursacht durch die neue Unterstützung für die Reflexion von partiellen Indizes auf SQLite, die in 1.4.45 für #8804 hinzugefügt wurde, bei der der index_list pragma-Befehl in sehr alten SQLite-Versionen (möglicherweise vor 3.8.9) nicht die erwartete Anzahl von Spalten zurückgibt, was zu Ausnahmen beim Reflektieren von Tabellen und Indizes führt.

  Referenzen: #8969

tests

• [tests] [bug]

  Behobenes Problem in der tox.ini-Datei, bei der Änderungen in der tox 4.0-Serie am Format von "passenv" dazu führten, dass tox nicht korrekt funktionierte, insbesondere mit einer Fehlermeldung ab tox 4.0.6.

• [tests] [bug]

  Neue Ausschlussregel für Drittanbieter-Dialekte namens unusual_column_name_characters hinzugefügt, die für Drittanbieter-Dialekte, die keine Spaltennamen mit ungewöhnlichen Zeichen wie Punkten, Schrägstrichen oder Prozentzeichen unterstützen, "geschlossen" werden kann, selbst wenn der Name korrekt zitiert ist.

  Referenzen: #9002

1.4.45

Veröffentlicht: 10. Dezember 2022

orm

• [orm] [bug]

  Behobener Fehler, bei dem Session.merge() den aktuellen geladenen Inhalt von Beziehungsattributen, die mit dem Parameter relationship.viewonly gekennzeichnet waren, nicht beibehielt und somit Strategien unterlief, die Session.merge() verwenden, um vollständig geladene Objekte aus Caches und ähnlichen Techniken abzurufen. In einer verwandten Änderung wurde ein Problem behoben, bei dem ein Objekt, das eine geladene Beziehung enthält, die aber auf der Zuordnung als lazy='raise' konfiguriert war, beim Übergeben an Session.merge() fehlschlug; Prüfungen auf "raise" werden nun während des Merge-Vorgangs ausgesetzt, vorausgesetzt, der Parameter Session.merge.load bleibt auf seinem Standardwert True.

  Insgesamt handelt es sich um eine Verhaltensanpassung einer Änderung, die in der 1.4-Serie ab #4994 eingeführt wurde und "merge" aus den standardmäßig auf "viewonly"-Beziehungen angewandten Kaskaden entfernt hat. Da "viewonly"-Beziehungen unter keinen Umständen persistent gespeichert werden, hat die Übertragung ihrer Inhalte während eines "merge" keine Auswirkungen auf das Persistenzverhalten des Zielobjekts. Dies ermöglicht es Session.merge(), einen seiner Anwendungsfälle korrekt zu erfüllen: das Hinzufügen von Objekten zu einer Session, die anderswo geladen wurden, oft zum Zweck der Wiederherstellung aus einem Cache.

  Referenzen: #8862

• [orm] [bug]

  Behobene Probleme mit with_expression(), bei denen Ausdrücke, die aus Spalten bestanden, die aus der umschließenden SELECT-Anweisung referenziert wurden, in einigen Kontexten keinen korrekten SQL renderten, wenn der Ausdruck einen Aliasnamen hatte, der dem Attribut entsprach, das query_expression() verwendete, auch wenn query_expression() keinen Standardausdruck hatte. Vorerst, wenn die query_expression() einen Standardausdruck hat, wird dieser Aliasname weiterhin für diesen Standard verwendet, und ein zusätzlicher Alias mit demselben Namen wird weiterhin ignoriert. Insgesamt ist dieser Fall ziemlich knifflig, daher könnten weitere Anpassungen erforderlich sein.

  Referenzen: #8881

engine

• [engine] [bug]

  Behobenes Problem, bei dem die Methode Result.freeze() für textuelles SQL mit entweder text() oder Connection.exec_driver_sql() nicht funktionierte.

  Referenzen: #8963

sql

• [sql] [anwendungsfall]

  Ein informatives Re-Raise wird nun ausgelöst, wenn ein "literal bindparam"-Render-Vorgang fehlschlägt, der den Wert selbst und den verwendeten Datentyp angibt, um bei der Fehlerbehebung zu helfen, wenn literale Parameter in einer Anweisung gerendert werden.

  Referenzen: #8800

• [sql] [bug]

  Behobene eine Reihe von Problemen bezüglich der Position und manchmal der Identität von gerenderten gebundenen Parametern, wie sie z. B. für SQLite, asyncpg, MySQL, Oracle und andere verwendet werden. Einige kompilierte Formen behielten die Reihenfolge der Parameter nicht korrekt bei, wie z. B. die PostgreSQL-Funktion regexp_replace(), die "nesting"-Funktion des CTE-Konstrukts, das zuerst in #4123 eingeführt wurde, und wählbare Tabellen, die durch die Verwendung der Methode FunctionElement.column_valued() mit Oracle gebildet wurden.

  Referenzen: #8827

asyncio

• [asyncio] [bug]

  Nicht funktionierende merge()-Methode aus AsyncResult entfernt. Diese Methode hat nie funktioniert und wurde fälschlicherweise in AsyncResult aufgenommen.

  Referenzen: #8952

postgresql

• [postgresql] [bug]

  Anpassung vorgenommen, wie der PostgreSQL-Dialekt Spaltentypen bei der Reflexion von Spalten aus einer Tabelle berücksichtigt, um alternative Backends zu unterstützen, die NULL von der PG-Funktion format_type() zurückgeben.

  Referenzen: #8748

sqlite

• [sqlite] [anwendungsfall]

  Unterstützung für das SQLite-Backend hinzugefügt, um die Schlüsselwörter "DEFERRABLE" und "INITIALLY" zu reflektieren, die in einem Fremdschlüsselkonstrukt vorhanden sein können. Pull Request von Michael Gorven.

  Referenzen: #8903

• [sqlite] [anwendungsfall]

  Unterstützung für die Reflexion von expression-orientierten WHERE-Kriterien, die in Indizes auf dem SQLite-Dialekt enthalten sind, auf ähnliche Weise wie beim PostgreSQL-Dialekt hinzugefügt. Pull Request von Tobias Pfeiffer.

  Referenzen: #8804

• [sqlite] [bug]

  Zurückportierte Korrektur für die SQLite-Reflexion von eindeutigen Constraints in angehängten Schemata, veröffentlicht in 2.0 als kleiner Teil von #4379. Zuvor wurden eindeutige Constraints in angehängten Schemata von der SQLite-Reflexion ignoriert. Pull Request von Michael Gorven.

  Referenzen: #8866

oracle

• [oracle] [bug]

  Fortsetzung von Korrekturen für die Oracle-Korrektur #8708, veröffentlicht in 1.4.43, bei der gebundene Parameternamen, die mit Unterstrichen beginnen und von Oracle nicht zugelassen werden, immer noch nicht in allen Fällen ordnungsgemäß escaped wurden.

  Referenzen: #8708

• [oracle] [bug]

  Behobenes Problem im Oracle-Compiler, bei dem die Syntax für FunctionElement.column_valued() falsch war und der Name COLUMN_VALUE gerendert wurde, ohne die Quelltabelle korrekt zu qualifizieren.

  Referenzen: #8945

1.4.44

Veröffentlicht: 12. November 2022

sql

• [sql] [bug]

  Kritische Speicherprobleme bei der Generierung von Cache-Schlüsseln behoben, bei denen für sehr große und komplexe ORM-Anweisungen, die viele ORM-Aliase mit Unterabfragen verwenden, die Generierung von Cache-Schlüsseln exzessiv große Schlüssel erzeugen konnte, die um Größenordnungen größer waren als die Anweisung selbst. Viel Dank an Rollo Konig Brock für seine geduldige und langfristige Hilfe bei der endgültigen Identifizierung dieses Problems.

  Referenzen: #8790

postgresql

• [postgresql] [bug] [mssql]

  Nur für die PostgreSQL- und SQL Server-Dialekte wurde der Compiler angepasst, so dass beim Rendern von Spaltenausdrücken in der RETURNING-Klausel das "non anon"-Label, das in SELECT-Anweisungen verwendet wird, für SQL-Ausdruckselemente, die ein Label generieren, vorgeschlagen wird; das Hauptbeispiel ist eine SQL-Funktion, die als Teil des Spaltentyps ausgegeben wird, wobei der Labelname standardmäßig dem Spaltennamen entsprechen sollte. Dies stellt ein nicht gut definiertes Verhalten wieder her, das sich in Version 1.4.21 aufgrund von #6718 und #6710 geändert hatte. Der Oracle-Dialekt hat eine andere RETURNING-Implementierung und war von diesem Problem nicht betroffen. Version 2.0 bietet branchenweite Änderungen für die stark erweiterte Unterstützung von RETURNING auf anderen Backends.

  Referenzen: #8770

oracle

• [oracle] [bug]

  Behobenes Problem im Oracle-Dialekt, bei dem eine INSERT-Anweisung, die insert(some_table).values(...).returning(some_table) gegen ein vollständiges Table-Objekt auf einmal verwendete, nicht ausgeführt werden konnte und eine Ausnahme auslöste.

tests

• [tests] [bug]

  Behobenes Problem, bei dem der Parameter --disable-asyncio für die Testsuite die Ausführung von Greenlet-Tests nicht verhinderte und auch nicht verhinderte, dass die Suite ein "Wrapper"-Greenlet für die gesamte Suite verwendete. Dieser Parameter stellt nun sicher, dass bei seiner Einstellung kein Greenlet oder asyncio verwendet wird.

  Referenzen: #8793

• [tests] [bug]

  Die Testsuite, die das Mypy-Plugin testet, wurde angepasst, um Änderungen in Mypy 0.990 zu berücksichtigen, wie es Nachrichten ausgibt, was sich auf die Interpretation von sys.path auswirkt, wenn entschieden wird, ob Notizen und Fehler für bestimmte Dateien gedruckt werden sollen. Die Änderung brach die Testsuite, da die Dateien im Testverzeichnis selbst keine Nachrichten mehr ausgaben, wenn sie über die mypy-API ausgeführt wurden.

1.4.43

Veröffentlicht: 4. November 2022

orm

• [orm] [bug]

  Behobenes Problem beim Joined Eager Loading, bei dem eine Assertion fehlschlug bei einer bestimmten Kombination von Outer/Inner Joined Eager Loads, wenn über drei Mapper Eager Loading erfolgte, wobei der mittlere Mapper ein geerbter Subklassen-Mapper war.

  Referenzen: #8738

• [orm] [bug]

  Behobener Fehler mit Select-Konstrukten, bei denen Kombinationen von Select.select_from() mit Select.join(), sowie bei der Verwendung von Select.join_from(), dazu führten, dass die Funktion with_loader_criteria() sowie die IN-Kriterien, die für Single-Table-Inheritance-Abfragen benötigt werden, nicht gerendert wurden, in Fällen, in denen die Spaltenklausel der Abfrage nicht explizit die linke Entität des JOIN enthielt. Die korrekte Entität wird nun an das intern generierte Join-Objekt übertragen, so dass die Kriterien gegen die linke Entität korrekt hinzugefügt werden.

  Referenzen: #8721

• [orm] [bug]

  Eine informative Ausnahme wird nun ausgelöst, wenn die Option with_loader_criteria() als Ladeoption zu einem bestimmten "Loader-Pfad" hinzugefügt wird, z. B. wenn sie innerhalb von Load.options() verwendet wird. Diese Verwendung wird nicht unterstützt, da with_loader_criteria() nur als Top-Level-Ladeoption verwendet werden darf. Zuvor wurde ein interner Fehler generiert.

  Referenzen: #8711

• [orm] [bug]

  Der "Dictionary-Modus" für Session.get() wurde verbessert, so dass Synonymnamen, die auf Primärschlüsselattributnamen verweisen, im benannten Wörterbuch angegeben werden können.

  Referenzen: #8753

• [orm] [bug]

  Behobenes Problem, bei dem die "selectin_polymorphic"-Ladung für Vererbungsmapper nicht korrekt funktionierte, wenn der Parameter Mapper.polymorphic_on auf einen SQL-Ausdruck verwies, der nicht direkt auf der Klasse abgebildet war.

  Referenzen: #8704

• [orm] [bug]

  Behobenes Problem, bei dem der zugrunde liegende DBAPI-Cursor nicht geschlossen wurde, wenn das Query-Objekt als Iterator verwendet wurde, wenn eine benutzerdefinierte Ausnahme innerhalb des Iterationsprozesses ausgelöst wurde, wodurch der Iterator vom Python-Interpreter geschlossen wurde. Bei Verwendung von Query.yield_per() zur Erstellung von Server-seitigen Cursors führte dies zu den üblichen MySQL-bezogenen Problemen mit Server-seitigen Cursors, die nicht synchron waren, und ohne direkten Zugriff auf das Result-Objekt konnte Endbenutzer-Code nicht auf den Cursor zugreifen, um ihn zu schließen.

  Zur Behebung wird ein Catch für GeneratorExit innerhalb der Iterator-Methode angewendet, was das Ergebnisobjekt in den Fällen schließt, in denen der Iterator unterbrochen wurde, und per Definition vom Python-Interpreter geschlossen wird.

  Als Teil dieser Änderung, wie sie für die 1.4-Serie implementiert wurde, wurde sichergestellt, dass .close()-Methoden für alle Result-Implementierungen, einschließlich ScalarResult und MappingResult, verfügbar sind. Die 2.0-Version dieser Änderung enthält auch neue Kontextmanager-Muster für die Verwendung mit Result-Klassen.

  Referenzen: #8710

engine

• [engine] [bug] [regression]

  Behebung eines Problems, bei dem der PoolEvents.reset()-Event-Hook in allen Fällen nicht aufgerufen wurde, wenn eine Connection geschlossen wurde und dabei ihre DBAPI-Verbindung an den Connection-Pool zurückgegeben wurde.

  Das Szenario war, wenn die Connection bereits .rollback() auf ihrer DBAPI-Verbindung innerhalb des Prozesses der Rückgabe der Verbindung an den Pool ausgelöst hatte, wo sie dann den Connection-Pool anwies, auf sein eigenes „Reset“ zu verzichten, um den zusätzlichen Methodenaufruf zu sparen. Dies verhinderte jedoch, dass benutzerdefinierte Pool-Reset-Schemata innerhalb dieses Hooks verwendet werden konnten, da solche Hooks per Definition mehr taten, als nur .rollback() aufzurufen, und unter allen Umständen aufgerufen werden mussten. Dies war eine Regression, die in Version 1.4 auftrat.

  Für Version 1.4 bleibt der PoolEvents.checkin() als alternativer Event-Hook für benutzerdefinierte „Reset“-Implementierungen weiterhin gültig. Version 2.0 wird eine verbesserte Version von PoolEvents.reset() enthalten, die für zusätzliche Szenarien wie die Beendigung von asyncio-Verbindungen aufgerufen wird und auch kontextbezogene Informationen über das Reset erhält, um „benutzerdefinierte Verbindungs-Reset“-Schemata zu ermöglichen, die auf unterschiedliche Reset-Szenarien unterschiedlich reagieren können.

  Referenzen: #8717

• [engine] [bug]

  Sichergestellt, dass alle Result-Objekte eine Result.close()-Methode sowie ein Result.closed-Attribut enthalten, auch für ScalarResult und MappingResult.

  Referenzen: #8710

sql

• [sql] [bug]

  Behebung eines Problems, das die korrekte Funktion des literal_column()-Konstrukts im Kontext eines Select-Konstrukts sowie an anderen Stellen, an denen „anonyme Bezeichnungen“ generiert werden könnten, verhinderte, wenn der Literal-Ausdruck Zeichen wie offene Klammern enthielt, die das Formatieren stören könnten, aufgrund eines Implementierungsdetails der Struktur für „anonyme Bezeichnungen“.

  Referenzen: #8724

mssql

• [mssql] [bug]

  Behebung eines Problems mit Inspector.has_table(), das bei Verwendung gegen eine temporäre Tabelle mit dem SQL Server-Dialekt bei einigen Azure-Varianten fehlschlug, aufgrund einer unnötigen Abfrage der Informationsschemata, die auf diesen Serverversionen nicht unterstützt wird. Pull-Request von Mike Barry.

  Referenzen: #8714

• [mssql] [bug] [reflection]

  Behebung eines Problems mit Inspector.has_table(), das bei Verwendung gegen eine View mit dem SQL Server-Dialekt fälschlicherweise False zurückgab, aufgrund einer Regression in der 1.4-Serie, die die Unterstützung dafür unter SQL Server entfernte. Das Problem tritt in der 2.0-Serie nicht auf, die eine andere Reflektionsarchitektur verwendet. Es werden Testunterstützungen hinzugefügt, um sicherzustellen, dass has_table() gemäß Spezifikation bezüglich Views weiterhin funktioniert.

  Referenzen: #8700

oracle

• [oracle] [bug]

  Behebung eines Problems, bei dem gebundene Parameternamen, einschließlich derer, die automatisch aus ähnlich benannten Datenbankspalten abgeleitet werden und Zeichen enthalten, die bei Oracle normalerweise Anführungszeichen erfordern, bei Verwendung von „erweiternden Parametern“ mit dem Oracle-Dialekt nicht escaped wurden, was zu Ausführungsfehlern führte. Die üblichen „Anführungszeichen“ für gebundene Parameter, die vom Oracle-Dialekt verwendet werden, werden bei der „erweiternden Parameter“-Architektur nicht verwendet, sodass stattdessen ein Escaping für eine große Bandbreite von Zeichen verwendet wird, nun unter Verwendung einer Liste von Zeichen/Escapes, die für Oracle spezifisch sind.

  Referenzen: #8708

• [oracle] [bug]

  Behebung eines Problems, bei dem die Ansicht nls_session_parameters, die beim ersten Verbindungsaufbau abgefragt wird, um das Standard-Dezimaltrennzeichen zu ermitteln, je nach Oracle-Verbindungsmodus möglicherweise nicht verfügbar war und daher einen Fehler auslöste. Der Ansatz zur Erkennung des Dezimalzeichens wurde vereinfacht, indem ein Dezimalwert direkt getestet wird, anstatt Systemansichten auszulesen, was auf jedem Backend/Treiber funktioniert.

  Referenzen: #8744

1.4.42

Veröffentlicht: 16. Oktober 2022

orm

• [orm] [bug]

  Das Wörterbuch Session.execute.bind_arguments wird beim Übergeben an Session.execute() und ähnliche nicht mehr mutiert; stattdessen wird es in ein internes Wörterbuch für Zustandsänderungen kopiert. Dies behebt unter anderem ein Problem, bei dem die an die Methode Session.get_bind() übergebene „Klausel“ fälschlicherweise auf den Select-Konstrukt für die „Fetch“-Synchronisierungsstrategie verwies, wenn die tatsächlich ausgegebene Abfrage ein Delete- oder Update-Konstrukt war. Dies hätte Rezepte für „Routing-Sessions“ gestört.

  Referenzen: #8614

• [orm] [bug]

  In ORM-Konfigurationen wird eine Warnung ausgegeben, wenn eine explizite remote()-Annotation auf Spalten angewendet wird, die lokal zur unmittelbar zugeordneten Klasse sind, wenn die referenzierte Klasse keine der gleichen Tabellenspalten enthält. Idealerweise würde dies irgendwann zu einem Fehler führen, da es aus Sicht der Zuordnung nicht korrekt ist.

  Referenzen: #7094

• [orm] [bug]

  Es wird eine Warnung ausgegeben, wenn versucht wird, eine zugeordnete Klasse innerhalb einer Vererbungshierarchie zu konfigurieren, bei der dem Mapper keine polymorphe Identität zugewiesen ist, es aber eine polymorphe Diskriminatorspalte gibt. Solche Klassen sollten abstrakt sein, wenn sie niemals direkt geladen werden sollen.

  Referenzen: #7545

• [orm] [bug] [regression]

  Behebung einer Regression für 1.4 in contains_eager(), bei der die Logik zum „Einwickeln in eine Subquery“ von joinedload() unbeabsichtigt für die Verwendung der Funktion contains_eager() mit ähnlichen Anweisungen (z. B. solche, die distinct(), limit() oder offset() verwenden) ausgelöst wurde, was dann zu sekundären Problemen mit Abfragen führte, die einige Kombinationen von SQL-Labelnamen und Aliasing verwendeten. Dieses „Einschließen“ ist für contains_eager() nicht angemessen, das immer den Vertrag hatte, dass die vom Benutzer definierte SQL-Anweisung unverändert bleibt, mit Ausnahme des Hinzufügens der entsprechenden abzurufenden Spalten.

  Referenzen: #8569

• [orm] [bug] [regression]

  Behebung einer Regression, bei der die Verwendung von ORM update() mit synchronize_session=’fetch’ fehlschlug, aufgrund der Verwendung von Evaluatoren, die nun verwendet werden, um den In-Python-Wert für Ausdrücke in der SET-Klausel beim Aktualisieren von Objekten zu bestimmen; wenn die Evaluatoren mathematische Operatoren auf nicht-numerische Werte wie PostgreSQL JSONB anwenden, wurde die nicht evaluierbare Bedingung nicht korrekt erkannt. Der Evaluator beschränkt nun die Verwendung von mathematischen Mutationsoperatoren nur auf numerische Typen, mit Ausnahme von „+“, das weiterhin auch für Zeichenfolgen funktioniert. SQLAlchemy 2.0 könnte dies weiter ändern, indem die SET-Werte vollständig abgerufen und nicht durch Auswertung ermittelt werden.

  Referenzen: #8507

engine

• [engine] [bug]

  Behebung eines Problems, bei dem die Mischung von „*“ mit zusätzlichen explizit benannten Spaltenausdrücken in der Spaltenklausel eines select()-Konstrukts dazu führte, dass die Ergebnisspaltenausrichtung manchmal den Spaltennamen oder andere nicht wiederholte Namen als mehrdeutiges Ziel betrachtete.

  Referenzen: #8536

asyncio

• [asyncio] [bug]

  Verbesserte Implementierung von asyncio.shield(), das in Kontextmanagern wie in #8145 hinzugefügt wurde, so dass der „close“-Vorgang innerhalb eines asyncio.Task eingeschlossen ist, der dann stark referenziert wird, während der Vorgang fortschreitet. Dies entspricht der Python-Dokumentation, die besagt, dass die Aufgabe andernfalls nicht stark referenziert wird.

  Referenzen: #8516

postgresql

• [postgresql] [usecase]

  aggregate_order_by unterstützt jetzt die Cache-Generierung.

  Referenzen: #8574

mysql

• [mysql] [bug]

  Angepasste reguläre Ausdruck, der zum Abgleichen von „CREATE VIEW“ beim Testen auf Views verwendet wird, um flexibler zu arbeiten, wobei das Schlüsselwort „ALGORITHM“ in der Mitte nicht mehr erforderlich ist, das optional sein sollte, aber nicht korrekt funktionierte. Die Änderung ermöglicht die View-Reflektion auf MySQL-kompatiblen Varianten wie StarRocks vollständiger. Pull-Request von John Bodley.

  Referenzen: #8588

mssql

• [mssql] [bug] [regression]

  Behebung einer weiteren Regression bei der Abfrage des SQL Server-Isolationslevels (siehe #8231, #8475), diesmal mit „Microsoft Dynamics CRM Database via Azure Active Directory“, dem anscheinend die View system_views vollständig fehlt. Die Fehlerbehandlung wurde erweitert, sodass diese Methode unter keinen Umständen fehlschlägt, sofern eine Datenbankverbindung vorhanden ist.

  Referenzen: #8525

1.4.41

Veröffentlicht: 6. September 2022

orm

• [orm] [bug] [events]

  Behebung eines Problems bei der Ereignisverfolgung, bei dem an eine Oberklasse angefügte Ereignis-Listener verloren gingen, wenn eine Unterklasse erstellt wurde, die dann eigene Listener hatte. Das praktische Beispiel ist die Klasse sessionmaker, die nach der Zuordnung von Ereignissen zur Klasse Session erstellt wurde.

  Referenzen: #8467

• [orm] [bug]

  Die Cache-Schlüsselstrategie für die Konstrukte aliased() und with_polymorphic() wurde gehärtet. Obwohl kein Problem mit tatsächlich gecachten Anweisungen leicht (wenn überhaupt) nachweisbar ist, enthielten diese beiden Konstrukte nicht genug von dem, was sie einzigartig macht, in ihren Cache-Schlüsseln, sodass das Caching auf dem aliased Konstrukt allein nicht korrekt war.

  Referenzen: #8401

• [orm] [bug] [regression]

  Behebung einer Regression in der 1.4-Serie, bei der eine Joined-Inheritance-Abfrage, die als Subquery innerhalb einer umschließenden Abfrage für dieselbe Entität platziert wurde, die JOINs für die innere Abfrage nicht korrekt rendern konnte. Das Problem manifestierte sich vor und nach Version 1.4.18 (verwandtes Problem #6595) auf zwei verschiedene Arten: einmal wurde JOIN zweimal gerendert, im anderen Fall ging der JOIN verloren. Zur Behebung wurden die Bedingungen, unter denen „polymorphes Laden“ angewendet wird, reduziert, sodass sie für einfache Joined-Inheritance-Abfragen nicht mehr ausgelöst werden.

  Referenzen: #8456

• [orm] [bug]

  Behebung eines Problems in der Erweiterung sqlalchemy.ext.mutable, bei der Sammlungslinks zum übergeordneten Objekt verloren gingen, wenn das Objekt mit Session.merge() zusammengeführt wurde, während gleichzeitig Session.merge.load als False übergeben wurde.

  Referenzen: #8446

• [orm] [bug]

  Behebung eines Problems mit with_loader_criteria(), bei dem eine Closure-Variable, die als gebundener Parameterwert innerhalb der Lambda-Funktion verwendet wurde, nach dem Caching der Anweisung nicht korrekt an zusätzliche Beziehungs-Loader wie selectinload() und lazyload() weitergegeben wurde und stattdessen den veralteten ursprünglich gecachten Wert verwendete.

  Referenzen: #8399

sql

• [sql] [bug]

  Behebung eines Problems, bei dem die Verwendung des table()-Konstrukts, das einen String für den Parameter table.schema übergibt, den „Schema“-String bei der Erzeugung eines Cache-Schlüssels nicht berücksichtigte, was zu Cache-Kollisionen führte, wenn mehrere gleichnamige table()-Konstrukte mit unterschiedlichen Schemata verwendet wurden.

  Referenzen: #8441

asyncio

• [asyncio] [bug]

  Unterstützung für die terminate()-Methode von asyncpg wurde integriert, für Fälle, in denen der Connection-Pool eine möglicherweise abgelaufene Verbindung wiederverwendet, wenn eine Verbindung aufgeräumt wird, die nicht ordnungsgemäß geschlossen wurde, sowie wenn die Verbindung ungültig geworden ist. Dies ermöglicht es asyncpg, die Verbindung abzubrechen, ohne auf eine Antwort zu warten, die möglicherweise lange Timeouts verursacht.

  Referenzen: #8419

mssql

• [mssql] [bug] [regression]

  Behebung einer Regression, die durch die Korrektur für #8231 in 1.4.40 verursacht wurde, bei der die Verbindung fehlschlug, wenn der Benutzer keine Berechtigung zum Abfragen der Systemansichten dm_exec_sessions oder dm_pdw_nodes_exec_sessions hatte, als versucht wurde, das aktuelle Transaktionsisolationslevel zu ermitteln.

  Referenzen: #8475

1.4.40

Veröffentlicht: 8. August 2022

orm

• [orm] [bug]

  Behebung eines Problems, bei dem die mehrfache Referenzierung einer CTE in Verbindung mit einer polymorphen SELECT-Anweisung dazu führen konnte, dass mehrere „Klone“ derselben CTE konstruiert wurden, was dann diese beiden CTEs als Duplikate auslöste. Zur Behebung werden die beiden CTEs tief verglichen, wenn dies auftritt, um sicherzustellen, dass sie gleichwertig sind, und dann als gleichwertig behandelt.

  Referenzen: #8357

• [orm] [bug]

  Eine select()-Konstruktion, der ein alleiniges Argument ‚*‘ für SELECT * übergeben wird, entweder als String, über text() oder literal_column(), wird als SQL-Anweisung auf Core-Ebene interpretiert und nicht als Anweisung auf ORM-Ebene. Dies geschieht, damit der *, wenn er erweitert wird, um eine beliebige Anzahl von Spalten zu berücksichtigen, alle zurückgegebenen Spalten im Ergebnis liefert. Die Interpretation von select() auf ORM-Ebene benötigt im Voraus die Namen und Typen aller ORM-Spalten, was nicht erreicht werden kann, wenn '*' verwendet wird.

  Wenn ‚*‘ gleichzeitig mit anderen Ausdrücken zusammen mit einer ORM-Anweisung verwendet wird, wird ein Fehler ausgelöst, da dies vom ORM nicht korrekt interpretiert werden kann.

  Referenzen: #8235

orm declarative

• [orm] [declarative] [bug]

  Behebung eines Problems, bei dem eine Hierarchie von Klassen, die als abstrakte oder Mixin-Deklarationsklassen eingerichtet waren, keine eigenständigen Spalten auf einer Oberklasse deklarieren konnten, die dann korrekt an einen aufrufbaren declared_attr kopiert wurden, der sie auf einer Nachklasse verwenden wollte.

  Referenzen: #8190

engine

• [engine] [usecase]

  Implementierung der neuen Auslegungsoption Connection.execution_options.yield_per für Connection in Core, um die gleichnamige Auslegungsoption yield_per im ORM zu spiegeln. Die Option setzt sowohl die Option Connection.execution_options.stream_results als auch die Aufrufung von Result.yield_per(), um die gängigste Streaming-Ergebnis-Konfiguration bereitzustellen, die auch das Nutzungsmuster des ORM-Anwendungsfalls widerspiegelt.

  Siehe auch

  Server-seitige Cursor verwenden (auch bekannt als Streaming von Ergebnissen) - überarbeitete Dokumentation

• [engine] [bug]

  Behebung eines Fehlers in Result, bei dem die Verwendung einer gepufferten Ergebnisstrategie nicht angewendet wurde, wenn der verwendete Dialekt keine explizite „Server-seitiger Cursor“-Einstellung unterstützte, wenn Connection.execution_options.stream_results verwendet wurde. Dies ist ein Fehler, da DBAPIs wie die von SQLite und Oracle bereits ein nicht-gepuffertes Ergebnisabrufschema verwenden, das dennoch von der teilweisen Ergebnisabfrage profitiert. Die „gepufferte“ Strategie wird nun in allen Fällen verwendet, in denen Connection.execution_options.stream_results gesetzt ist.

• [engine] [bug]

  Added FilterResult.yield_per(), so that result implementations like MappingResult, ScalarResult and AsyncResult get access to this method.

  References: #8199

sql

• [sql] [bug]

  Adjusted the SQL compilation for string containment functions .contains(), .startswith(), .endswith() to force the use of the string concatenation operator, rather than relying upon the overload of the addition operator, so that non-standard use of these operators with for example bytestrings still produces string concatenation operators.

  References: #8253

mypy

• [mypy] [bug]

  Fixed a crash of the mypy plugin when using a lambda as a Column default. Pull request courtesy of tchapi.

  References: #8196

asyncio

• [asyncio] [bug]

  Added asyncio.shield() to the connection and session release process specifically within the __aexit__() context manager exit, when using AsyncConnection or AsyncSession as a context manager that releases the object when the context manager is complete. This appears to help with task cancellation when using alternate concurrency libraries such as anyio, uvloop that otherwise don’t provide an async context for the connection pool to release the connection properly during task cancellation.

  References: #8145

postgresql

• [postgresql] [bug]

  Fixed issue in psycopg2 dialect where the “multiple hosts” feature implemented for #4392, where multiple host:port pairs could be passed in the query string as ?host=host1:port1&host=host2:port2&host=host3:port3 was not implemented correctly, as it did not propagate the “port” parameter appropriately. Connections that didn’t use a different “port” likely worked without issue, and connections that had “port” for some of the entries may have incorrectly passed on that hostname. The format is now corrected to pass hosts/ports appropriately.

  As part of this change, maintained support for another multihost style that worked unintentionally, which is comma-separated ?host=h1,h2,h3&port=p1,p2,p3. This format is more consistent with libpq’s query-string format, whereas the previous format is inspired by a different aspect of libpq’s URI format but is not quite the same thing.

  If the two styles are mixed together, an error is raised as this is ambiguous.

  References: #4392

mssql

• [mssql] [bug]

  Fixed issues that prevented the new usage patterns for using DML with ORM objects presented at Using INSERT, UPDATE and ON CONFLICT (i.e. upsert) to return ORM Objects from working correctly with the SQL Server pyodbc dialect.

  References: #8210

• [mssql] [bug]

  Fixed issue where the SQL Server dialect’s query for the current isolation level would fail on Azure Synapse Analytics, due to the way in which this database handles transaction rollbacks after an error has occurred. The initial query has been modified to no longer rely upon catching an error when attempting to detect the appropriate system view. Additionally, to better support this database’s very specific “rollback” behavior, implemented new parameter ignore_no_transaction_on_rollback indicating that a rollback should ignore Azure Synapse error ‘No corresponding transaction found. (111214)’, which is raised if no transaction is present in conflict with the Python DBAPI.

  Initial patch and valuable debugging assistance courtesy of @ww2406.

  Siehe auch

  Avoiding transaction-related exceptions on Azure Synapse Analytics

  References: #8231

misc

• [bug] [types]

  Fixed issue where TypeDecorator would not correctly proxy the __getitem__() operator when decorating the ARRAY datatype, without explicit workarounds.

  References: #7249

1.4.39

Released: June 24, 2022

orm

• [orm] [bug] [regression]

  Fixed regression caused by #8133 where the pickle format for mutable attributes was changed, without a fallback to recognize the old format, causing in-place upgrades of SQLAlchemy to no longer be able to read pickled data from previous versions. A check plus a fallback for the old format is now in place.

  References: #8133

1.4.38

Released: June 23, 2022

orm

• [orm] [bug] [regression]

  Fixed regression caused by #8064 where a particular check for column correspondence was made too liberal, resulting in incorrect rendering for some ORM subqueries such as those using PropComparator.has() or PropComparator.any() in conjunction with joined-inheritance queries that also use legacy aliasing features.

  References: #8162

• [orm] [bug] [sql]

  Fixed an issue where GenerativeSelect.fetch() would not be applied when executing a statement using the ORM.

  References: #8091

• [orm] [bug]

  Fixed issue where a with_loader_criteria() option could not be pickled, as is necessary when it is carried along for propagation to lazy loaders in conjunction with a caching scheme. Currently, the only form that is supported as picklable is to pass the “where criteria” as a fixed module-level callable function that produces a SQL expression. An ad-hoc “lambda” can’t be pickled, and a SQL expression object is usually not fully picklable directly.

  References: #8109

engine

• [engine] [bug]

  Repaired a deprecation warning class decorator that was preventing key objects such as Connection from having a proper __weakref__ attribute, causing operations like Python standard library inspect.getmembers() to fail.

  References: #8115

sql

• [sql] [bug]

  Fixed multiple observed race conditions related to lambda_stmt(), including an initial “dogpile” issue when a new Python code object is initially analyzed among multiple simultaneous threads which created both a performance issue as well as some internal corruption of state. Additionally repaired observed race condition which could occur when “cloning” an expression construct that is also in the process of being compiled or otherwise accessed in a different thread due to memoized attributes altering the __dict__ while iterated, for Python versions prior to 3.10; in particular the lambda SQL construct is sensitive to this as it holds onto a single statement object persistently. The iteration has been refined to use dict.copy() with or without an additional iteration instead.

  References: #8098

• [sql] [bug]

  Enhanced the mechanism of Cast and other “wrapping” column constructs to more fully preserve a wrapped Label construct, including that the label name will be preserved in the .c collection of a Subquery. The label was already able to render in the SQL correctly on the outside of the construct which it was wrapped inside.

  References: #8084

• [sql] [bug]

  Adjusted the fix made for #8056 which adjusted the escaping of bound parameter names with special characters such that the escaped names were translated after the SQL compilation step, which broke a published recipe on the FAQ illustrating how to merge parameter names into the string output of a compiled SQL string. The change restores the escaped names that come from compiled.params and adds a conditional parameter to SQLCompiler.construct_params() named escape_names that defaults to True, restoring the old behavior by default.

  References: #8113

schema

• [schema] [bug]

  Fixed bugs involving the Table.include_columns and the Table.resolve_fks parameters on Table; these little-used parameters were apparently not working for columns that refer to foreign key constraints.

  In the first case, not-included columns that refer to foreign keys would still attempt to create a ForeignKey object, producing errors when attempting to resolve the columns for the foreign key constraint within reflection; foreign key constraints that refer to skipped columns are now omitted from the table reflection process in the same way as occurs for Index and UniqueConstraint objects with the same conditions. No warning is produced however, as we likely want to remove the include_columns warnings for all constraints in 2.0.

  In the latter case, the production of table aliases or subqueries would fail on an FK related table not found despite the presence of resolve_fks=False; the logic has been repaired so that if a related table is not found, the ForeignKey object is still proxied to the aliased table or subquery (these ForeignKey objects are normally used in the production of join conditions), but it is sent with a flag that it’s not resolvable. The aliased table / subquery will then work normally, with the exception that it cannot be used to generate a join condition automatically, as the foreign key information is missing. This was already the behavior for such foreign key constraints produced using non-reflection methods, such as joining Table objects from different MetaData collections.

  References: #8100, #8101

• [schema] [bug] [mssql]

  Fixed issue where Table objects that made use of IDENTITY columns with a Numeric datatype would produce errors when attempting to reconcile the “autoincrement” column, preventing construction of the Column from using the Column.autoincrement parameter as well as emitting errors when attempting to invoke an Insert construct.

  References: #8111

extensions

• [extensions] [bug]

  Fixed bug in Mutable where pickling and unpickling of an ORM mapped instance would not correctly restore state for mappings that contained multiple Mutable-enabled attributes.

  References: #8133

1.4.37

Released: May 31, 2022

orm

• [orm] [bug]

  Fixed issue where using a column_property() construct containing a subquery against an already-mapped column attribute would not correctly apply ORM-compilation behaviors to the subquery, including that the “IN” expression added for a single-table inherits expression would fail to be included.

  References: #8064

• [orm] [bug]

  Fixed issue where ORM results would apply incorrect key names to the returned Row objects in the case where the set of columns to be selected were changed, such as when using Select.with_only_columns().

  References: #8001

• [orm] [bug] [oracle] [postgresql]

  Fixed bug, likely a regression from 1.3, where usage of column names that require bound parameter escaping, more concretely when using Oracle with column names that require quoting such as those that start with an underscore, or in less common cases with some PostgreSQL drivers when using column names that contain percent signs, would cause the ORM versioning feature to not work correctly if the versioning column itself had such a name, as the ORM assumes certain bound parameter naming conventions that were being interfered with via the quotes. This issue is related to #8053 and essentially revises the approach towards fixing this, revising the original issue #5653 that created the initial implementation for generalized bound-parameter name quoting.

  References: #8056

engine

• [engine] [bug] [tests]

  Fixed issue where support for logging “stacklevel” implemented in #7612 required adjustment to work with recently released Python 3.11.0b1, also repairs the unit tests which tested this feature.

  References: #8019

sql

• [sql] [bug] [postgresql] [sqlite]

  Fixed bug where the PostgreSQL Insert.on_conflict_do_update() method and the SQLite Insert.on_conflict_do_update() method would both fail to correctly accommodate a column with a separate “.key” when specifying the column using its key name in the dictionary passed to Insert.on_conflict_do_update.set_, as well as if the Insert.excluded collection were used as the dictionary directly.

  References: #8014

• [sql] [bug]

  An informative error is raised for the use case where Insert.from_select() is being passed a “compound select” object such as a UNION, yet the INSERT statement needs to append additional columns to support Python-side or explicit SQL defaults from the table metadata. In this case a subquery of the compound object should be passed.

  References: #8073

• [sql] [bug]

  Fixed an issue where using bindparam() with no explicit data or type given could be coerced into the incorrect type when used in expressions such as when using Comparator.any() and Comparator.all().

  References: #7979

• [sql] [bug]

  An informative error is raised if two individual BindParameter objects share the same name, yet one is used within an “expanding” context (typically an IN expression) and the other is not; mixing the same name in these two different styles of usage is not supported and typically the expanding=True parameter should be set on the parameters that are to receive list values outside of IN expressions (where expanding is set by default).

  References: #8018

mysql

• [mysql] [bug]

  Further adjustments to the MySQL PyODBC dialect to allow for complete connectivity, which was previously still not working despite fixes in #7871.

  References: #7966

• [mysql] [bug]

  Added disconnect code for MySQL error 4031, introduced in MySQL >= 8.0.24, indicating connection idle timeout exceeded. In particular this repairs an issue where pre-ping could not reconnect on a timed-out connection. Pull request courtesy valievkarim.

  References: #8036

mssql

• [mssql] [bug]

  Fix issue where a password with a leading “{” would result in login failure.

  References: #8062

• [mssql] [bug] [reflection]

  Explicitly specify the collation when reflecting table columns using MSSQL to prevent “collation conflict” errors.

  References: #8035

oracle

• [oracle] [usecase]

  Added two new error codes for Oracle disconnect handling to support early testing of the new “python-oracledb” driver released by Oracle.

  References: #8066

• [oracle] [bug]

  Fixed SQL compiler issue where the “bind processing” function for a bound parameter would not be correctly applied to a bound value if the bound parameter’s name were “escaped”. Concretely, this applies, among other cases, to Oracle when a Column has a name that itself requires quoting, such that the quoting-required name is then used for the bound parameters generated within DML statements, and the datatype in use requires bind processing, such as the Enum datatype.

  References: #8053

1.4.36

Released: April 26, 2022

orm

• [orm] [bug] [regression]

  Fixed regression where the change made for #7861, released in version 1.4.33, that brought the Insert construct to be partially recognized as an ORM-enabled statement did not properly transfer the correct mapper / mapped table state to the Session, causing the Session.get_bind() method to fail for a Session that was bound to engines and/or connections using the Session.binds parameter.

  References: #7936

orm declarative

• [orm] [declarative] [bug]

  Modified the DeclarativeMeta metaclass to pass cls.__dict__ into the declarative scanning process to look for attributes, rather than the separate dictionary passed to the type’s __init__() method. This allows user-defined base classes that add attributes within an __init_subclass__() to work as expected, as __init_subclass__() can only affect the cls.__dict__ itself and not the other dictionary. This is technically a regression from 1.3 where __dict__ was being used.

  References: #7900

engine

• [engine] [bug]

  Ein Speicherleck in den C-Erweiterungen, das beim Aufruf benannter Member von Row auftreten konnte, wenn der Member unter Python 3 nicht existiert, wurde behoben. Dies konnte insbesondere bei NumPy-Transformationen auftreten, wenn versucht wurde, Member wie .__array__ aufzurufen, aber das Problem um jeden AttributeError betraf, der vom Row-Objekt ausgelöst wurde. Dieses Problem gilt nicht für Version 2.0, die bereits zu Cython migriert ist. Vielen Dank an Sebastian Berg für die Identifizierung des Problems.

  Referenzen: #7875

• [engine] [bug]

  Eine Warnung bezüglich eines Fehlers in der Methode Result.columns() wurde hinzugefügt, wenn 0 für den Index in Verbindung mit einem Result übergeben wird, der nur eine einzige ORM-Entität zurückgibt. Dies deutet darauf hin, dass das aktuelle Verhalten von Result.columns() in diesem Fall fehlerhaft ist, da das Result-Objekt Skalarwerte und nicht Row-Objekte liefert. Das Problem wird in 2.0 behoben, was eine rückwärtskompatible Änderung für Code wäre, der auf dem aktuellen fehlerhaften Verhalten basiert. Code, der eine Sammlung von Skalarwerten erhalten möchte, sollte die Methode Result.scalars() verwenden, die ein neues ScalarResult-Objekt zurückgibt, das nicht-Zeilen-Skalarobjekte liefert.

  Referenzen: #7953

schema

• [schema] [bug]

  Es wurde ein Fehler behoben, bei dem Namenskonventionen für ForeignKeyConstraint, die die Namenskonvention referred_column_0 verwendeten, nicht funktionierten, wenn die Fremdschlüsselbeschränkung als ForeignKey-Objekt und nicht als explizites ForeignKeyConstraint-Objekt eingerichtet war. Da diese Änderung eine Portierung einiger Fixes aus Version 2.0 verwendet, wird auch eine zusätzliche, wenig bekannte Funktion behoben, die wahrscheinlich seit vielen Jahren fehlerhaft war: Ein ForeignKey-Objekt kann sich auf eine referenzierte Tabelle nur mit dem Namen der Tabelle beziehen, ohne einen Spaltennamen zu verwenden, wenn der Name der referenzierten Spalte derselbe ist wie der der referenzierenden Spalte.

  Die Namenskonvention referred_column_0 wurde zuvor nur mit dem ForeignKeyConstraint-Objekt getestet, nicht mit dem ForeignKey-Objekt. Dieser Fehler zeigt, dass die Funktion nie korrekt funktionierte, es sei denn, ForeignKeyConstraint wurde für alle FK-Beschränkungen verwendet. Dieser Fehler lässt sich auf die ursprüngliche Einführung der Funktion zurückführen, die für #3989 eingeführt wurde.

  Referenzen: #7958

asyncio

• [asyncio] [bug]

  Die Handhabung von contextvar.ContextVar-Objekten in asynchron angepassten Ereignisbehandlern wurde repariert. Zuvor wurden Werte, die einem ContextVar zugewiesen wurden, in dem speziellen Fall des Aufrufs von Awaitables in nicht-awaitablem Code nicht weitergegeben.

  Referenzen: #7937

postgresql

• [postgresql] [bug]

  Ein Fehler im Datentyp ARRAY in Kombination mit Enum unter PostgreSQL wurde behoben, bei dem die Methoden .any() oder .all() zur Generierung von SQL ANY() oder ALL() mit Mitgliedern der Python-Enumeration als Argumente einen Typanpassungsfehler bei allen Treibern verursachten.

  Referenzen: #6515

• [postgresql] [bug]

  Das Attribut UUID.python_type für den PostgreSQL UUID-Typ wurde implementiert. Das Attribut gibt entweder str oder uuid.UUID zurück, basierend auf der Einstellung des Parameters UUID.as_uuid. Zuvor war dieses Attribut nicht implementiert. Pull Request von Alex Grönholm.

  Referenzen: #7943

• [postgresql] [bug]

  Ein Problem im psycopg2-Dialekt wurde behoben, bei dem die Verwendung des Parameters create_engine.pool_pre_ping dazu führte, dass die benutzerdefinierte Isolationsstufe AUTOCOMMIT durch den „Ping“-Handler versehentlich zurückgesetzt wurde.

  Referenzen: #7930

mysql

• [mysql] [bug] [regression]

  Eine Regression im nicht getesteten MySQL PyODBC-Dialekt wurde behoben, die durch den Fix für #7518 in Version 1.4.32 verursacht wurde, bei der ein Argument beim ersten Verbindungsaufbau falsch weitergegeben wurde, was zu einem TypeError führte.

  Referenzen: #7871

tests

• [tests] [bug]

  Für Drittanbieter-Dialekte wurde eine fehlende Anforderung für den Test-Suite SimpleUpdateDeleteTest repariert, die die Funktionsweise der „rowcount“-Funktion auf dem Ziel-Dialekt nicht überprüfte.

  Referenzen: #7919

1.4.35

Veröffentlicht: 6. April 2022

sql

• [sql] [bug]

  Ein Fehler in der neu implementierten Funktion FunctionElement.table_valued.joins_implicitly wurde behoben, bei der der Parameter nicht automatisch vom ursprünglichen TableValuedAlias-Objekt auf das sekundäre Objekt propagiert wurde, das beim Aufruf von TableValuedAlias.render_derived() oder TableValuedAlias.alias() erzeugt wurde.

  Zusätzlich wurden diese Probleme in TableValuedAlias behoben:

  • Ein potenzielles Speicherproblem, das auftreten konnte, wenn TableValuedAlias.render_derived() wiederholt gegen aufeinanderfolgende Kopien desselben Objekts aufgerufen wurde (für .alias() müssen wir derzeit immer noch vom vorherigen Element verketten. Es ist unklar, ob dies verbessert werden kann, aber dies ist das Standardverhalten für .alias() anderswo).

  • Ein Problem, bei dem individuelle Elementtypen verloren gingen, wenn TableValuedAlias.render_derived() oder TableValuedAlias.alias() aufgerufen wurde.

  Referenzen: #7890

• [sql] [bug] [regression]

  Eine durch #7823 verursachte Regression, die das Caching-System beeinträchtigte, wurde behoben. Gebundene Parameter, die innerhalb von ORM-Operationen wie dem polymorphen Laden „geklont“ wurden, erhielten in einigen Fällen nicht ihren korrekten Laufzeitwert, was zu fehlerhaften Bindungswerten führte.

  Referenzen: #7903

1.4.34

Veröffentlicht: 31. März 2022

orm

• [orm] [bug] [regression]

  Eine durch #7861 verursachte Regression wurde behoben, bei der das direkte Aufrufen einer Insert-Konstruktion, die ORM-Entitäten enthielt, über Session.execute() fehlschlug.

  Referenzen: #7878

postgresql

• [postgresql] [bug]

  Eine Korrektur für #6581 wurde zurückgenommen, bei der der Modus „executemany values“ für psycopg2 für alle „ON CONFLICT“-Varianten von INSERT deaktiviert wurde. Dies gilt nun nicht mehr für die Klausel „ON CONFLICT DO NOTHING“, die keine Parameter enthält und für den Modus „executemany values“ sicher ist. „ON CONFLICT DO UPDATE“ ist weiterhin vom Modus „executemany values“ blockiert, da in der DO UPDATE-Klausel zusätzliche Parameter vorhanden sein können, die nicht gebündelt werden können (was das ursprüngliche Problem ist, das von #6581 behoben wurde).

  Referenzen: #7880

1.4.33

Veröffentlicht: 31. März 2022

orm

• [orm] [usecase]

  Das Argument with_polymorphic.adapt_on_names wurde zur Funktion with_polymorphic() hinzugefügt. Dies ermöglicht es, eine polymorphe Ladung (typischerweise mit konkreter Zuordnung) gegen ein alternatives wählbares Element anzugeben, das sich anhand der Spaltennamen allein an das ursprüngliche zugeordnete wählbare Element anpasst.

  Referenzen: #7805

• [orm] [usecase]

  Neue Attribute UpdateBase.returning_column_descriptions und UpdateBase.entity_description wurden hinzugefügt, um die ORM-Attribute und -Entitäten inspizieren zu können, die als Teil einer Insert-, Update- oder Delete-Konstruktion installiert sind. Der Accessor Select.column_descriptions ist nun auch für reine Core-Wählbarkeiten implementiert.

  Referenzen: #7861

• [orm] [bug] [regression]

  Eine Regression in der „dynamischen“ Loader-Strategie wurde behoben, bei der die Methode Query.filter_by() keine geeignete Entität zum Filtern erhielt, wenn eine „sekundäre“ Tabelle in der abgefragten Beziehung vorhanden war und die Zuordnung zu etwas Komplexem wie „with polymorphic“ erfolgte.

  Referenzen: #7868

• [orm] [bug]

  Ein Fehler wurde behoben, bei dem composite()-Attribute nicht in Verbindung mit der selectin_polymorphic() Loader-Strategie für Joined Table Inheritance funktionierten.

  Referenzen: #7801

• [orm] [bug] [performance]

  Verbesserungen der Speichernutzung durch die ORM, wodurch eine erhebliche Anzahl von zwischengeschalteten Ausdrucksobjekten entfernt wurde, die typischerweise gespeichert werden, wenn eine Kopie eines Ausdrucksobjekts erstellt wird. Diese Klone wurden stark reduziert, wodurch die Anzahl der insgesamt im Speicher gespeicherten Ausdrucksobjekte durch ORM-Zuordnungen um etwa 30 % reduziert wurde.

  Referenzen: #7823

• [orm] [bug]

  Ein Problem wurde behoben, bei dem die Loader-Option selectin_polymorphic() nicht mit Joined-Inheritance-Mappern funktionierte, die keine feste „polymorphic_on“-Spalte hatten. Zusätzlich wurde die Testunterstützung für eine breitere Palette von Nutzungsmustern mit dieser Konstruktion hinzugefügt.

  Referenzen: #7799

• [orm] [bug]

  Ein Fehler in der Funktion with_loader_criteria() wurde behoben, bei der Loader-Kriterien nicht auf eine joined eager load angewendet wurden, die im Geltungsbereich einer Refresh-Operation für das Elternobjekt aufgerufen wurde.

  Referenzen: #7862

• [orm] [bug]

  Ein Problem wurde behoben, bei dem der Mapper ein vom Benutzer definiertes Mapper.primary_key-Argument zu aggressiv reduzierte, im Fall der Zuordnung zu einer UNION, bei der für einige der SELECT-Einträge zwei Spalten im Wesentlichen äquivalent sind, in einer anderen jedoch nicht, wie z.B. bei einer rekursiven CTE. Die Logik wurde geändert, um eine gegebene benutzerdefinierte PK so zu akzeptieren, wie sie ist, wobei Spalten mit dem zugeordneten wählbaren Element verbunden werden, aber nicht mehr „reduziert“ werden, da diese Heuristik nicht für alle Situationen geeignet ist.

  Referenzen: #7842

engine

• [engine] [usecase]

  Ein neuer Parameter Engine.dispose.close wurde hinzugefügt, der standardmäßig auf True gesetzt ist. Wenn False, berührt die Engine-Trennung die Verbindungen im alten Pool überhaupt nicht, sondern verwirft lediglich den Pool und ersetzt ihn. Dieser Anwendungsfall dient dazu, dass der übergeordnete Prozess diese Verbindungen weiterhin nutzen kann, wenn der ursprüngliche Pool von einem übergeordneten Prozess übertragen wird.

  Siehe auch

  Verwendung von Connection Pools mit Multiprocessing oder os.fork() - überarbeitete Dokumentation

  Referenzen: #7815, #7877

• [engine] [bug]

  Die Protokollierung auf Connection-Ebene wurde weiter präzisiert, um anzuzeigen, dass die BEGIN-, ROLLBACK- und COMMIT-Logmeldungen bei Verwendung der AUTOCOMMIT-Isolationsstufe keine echte Transaktion darstellen. Die Nachrichten wurden erweitert, um die BEGIN-Nachricht selbst einzuschließen, und die Nachrichten wurden auch korrigiert, um Fälle zu berücksichtigen, in denen der Parameter create_engine.isolation_level auf Engine-Ebene direkt verwendet wurde.

  Referenzen: #7853

sql

• [sql] [usecase]

  Ein neuer Parameter FunctionElement.table_valued.joins_implicitly wurde für den Konstrukt FunctionElement.table_valued() hinzugefügt. Dieser Parameter gibt an, dass die bereitgestellte tabellenwertige Funktion automatisch einen impliziten Join mit der referenzierten Tabelle durchführt. Dies deaktiviert effektiv die „from linting“-Funktion, wie z.B. die Warnung „cartesian product“, wenn dieser Parameter vorhanden ist. Kann für Funktionen wie func.json_each() verwendet werden.

  Referenzen: #7845

• [sql] [bug]

  Der Parameter bindparam.literal_execute ist nun Teil der Cache-Generierung eines bindparam(), da er die vom Compiler generierte SQL-Zeichenfolge ändert. Zuvor wurden die korrekten Bindungswerte verwendet, aber literal_execute wurde bei nachfolgenden Ausführungen derselben Abfrage ignoriert.

  Referenzen: #7876

• [sql] [bug] [regression]

  Eine durch #7760 verursachte Regression wurde behoben, bei der die neuen Fähigkeiten von TextualSelect nicht vollständig korrekt im Compiler implementiert waren, was zu Problemen bei zusammengesetzten INSERT-Konstrukten wie „INSERT FROM SELECT“ und „INSERT…ON CONFLICT“ in Kombination mit CTE und textuellen Anweisungen führte.

  Referenzen: #7798

schema

• [schema] [usecase]

  Es wurde Unterstützung hinzugefügt, so dass der aufrufbare Parameter Table.to_metadata.referred_schema_fn, der an Table.to_metadata() übergeben wird, den Wert BLANK_SCHEMA zurückgeben kann, um anzuzeigen, dass der referenzierte Fremdschlüssel auf None zurückgesetzt werden soll. Das Symbol RETAIN_SCHEMA kann ebenfalls von dieser Funktion zurückgegeben werden, um „keine Änderung“ anzuzeigen, was dasselbe Verhalten wie bei None hat, was ebenfalls keine Änderung anzeigt.

  Referenzen: #7860

sqlite

• [sqlite] [bug] [reflection]

  Ein Fehler wurde behoben, bei dem der Name von CHECK-Beschränkungen unter SQLite nicht reflektiert wurde, wenn der Name unter Verwendung von Anführungszeichen erstellt wurde, wie es der Fall ist, wenn der Name gemischte Groß-/Kleinschreibung oder Sonderzeichen enthält.

  Referenzen: #5463

mssql

• [mssql] [bug] [regression]

  Eine durch #7160 verursachte Regression wurde behoben, bei der die FK-Reflexion in Verbindung mit einer niedrigen Kompatibilitätsstufe (Kompatibilitätsstufe 80: SQL Server 2000) einen Fehler vom Typ „Ambiguous column name“ (Mehrdeutiger Spaltenname) verursachte. Patch von @Lin-Your.

  Referenzen: #7812

misc

• [bug] [ext]

  Die Fehlermeldung, die ausgelöst wird, wenn der Konstrukt association_proxy() versucht, auf ein Zielattribut auf Klassenebene zuzugreifen und dieser Zugriff fehlschlägt, wurde verbessert. Der spezielle Anwendungsfall hier ist das Proxieren zu einem Hybridattribut, das keine funktionierende Klassenimplementierung enthält.

  Referenzen: #7827

1.4.32

Veröffentlicht: 6. März 2022

orm

• [orm] [bug] [regression]

  Eine Regression wurde behoben, bei der die ORM-Ausnahme, die ausgelöst werden sollte, wenn ein INSERT lautlos keine Zeile einfügt (z.B. durch einen Trigger), nicht erreicht wurde. Dies geschah aufgrund einer Laufzeitausnahme, die vorzeitig ausgelöst wurde, weil der primäre Schlüsselwert fehlte, wodurch eine nicht informative Ausnahme anstelle der korrekten ausgelöst wurde. Für 1.4 und höher wird in diesem Fall ein neuer FlushError hinzugefügt, der früher als die bestehende „null identity“-Ausnahme für 1.3 ausgelöst wird, da eine Situation, in der die Anzahl der tatsächlich eingefügten Zeilen nicht mit der erwarteten übereinstimmt, in 1.4 kritischer ist, da sie verhindert, dass die Stapelverarbeitung mehrerer Objekte korrekt funktioniert. Dies ist getrennt von dem Fall, in dem ein neu abgerufener primärer Schlüssel als NULL abgerufen wird, was weiterhin die bestehende „null identity“-Ausnahme auslöst.

  Referenzen: #7594

• [orm] [bug]

  Ein Problem wurde behoben, bei dem die Verwendung eines vollständig qualifizierten Pfads für den Klassennamen in relationship(), der dennoch einen falschen Namen für Pfad-Tokens enthielt, die nicht das erste Token waren, keine informative Fehlermeldung auslöste und stattdessen zufällig zu einem späteren Zeitpunkt fehlschlug.

  Referenzen: #7697

engine

• [engine] [bug]

  Die Protokollierung für wichtige SQLAlchemy-Komponenten, einschließlich Engine und Connection, wurde angepasst, um einen geeigneten Stapel-Ebenen-Parameter festzulegen. Dadurch werden die Python-Logging-Tokens funcName und lineno bei Verwendung in benutzerdefinierten Formatierern die korrekten Informationen berichten, was bei der Filterung von Log-Ausgaben nützlich sein kann. Unterstützt ab Python 3.8. Pull Request von Markus Gerstel.

  Referenzen: #7612

sql

• [sql] [bug]

  Typbezogene Fehlermeldungen, die für Tupel-Werte aufgrund der String-Formatierungssyntax fehlschlugen, einschließlich der Kompilierung von nicht unterstützten Literalen und ungültigen booleschen Werten, wurden behoben.

  Referenzen: #7721

• [sql] [bug] [mysql]

  Probleme im MySQL SET-Datentyp sowie im generischen Enum-Datentyp wurden behoben, bei denen die Methode __repr__() nicht alle optionalen Parameter in der String-Ausgabe rendert, was die Verwendung dieser Typen in Alembic autogenerate beeinträchtigte. Pull Request für MySQL von Yuki Nishimine.

  Referenzen: #7598, #7720, #7789

• [sql] [bug]

  Der Datentyp Enum gibt nun eine Warnung aus, wenn das Argument Enum.length ohne Angabe von Enum.native_enum auf False gesetzt wird, da das Argument in diesem Fall stillschweigend ignoriert wird, obwohl der Datentyp Enum weiterhin VARCHAR DDL auf Backends rendert, die keinen nativen ENUM-Datentyp wie SQLite haben. Dieses Verhalten kann sich in einer zukünftigen Version ändern, sodass „length“ für alle nicht-nativen „enum“-Typen unabhängig von der Einstellung „native_enum“ berücksichtigt wird.

• [sql] [bug]

  Behoben wurde ein Problem, bei dem die Methode HasCTE.add_cte(), wenn sie auf einer TextualSelect-Instanz aufgerufen wurde, vom SQL-Compiler nicht verarbeitet wurde. Die Korrektur fügt außerdem mehr „SELECT“-ähnliches Compiler-Verhalten zu TextualSelect hinzu, einschließlich der Verarbeitung von DML CTEs wie UPDATE und INSERT.

  Referenzen: #7760

asyncio

• [asyncio] [bug]

  Behobene Probleme, bei denen keine aussagekräftige Fehlermeldung für einige Klassen des Event-Listenings mit einer Async-Engine ausgegeben wurde, die stattdessen eine Sync-Engine-Instanz sein sollte.

• [asyncio] [bug]

  Behobenes Problem, bei dem die Methode AsyncSession.execute() keine aussagekräftige Ausnahme auslöste, wenn die Ausführungsoption Connection.execution_options.stream_results verwendet wurde, die mit einem Sync-Style Result-Objekt inkompatibel ist, wenn ein Async-Calling-Stil verwendet wird, da die Operation zum Abrufen weiterer Zeilen asynchron erfolgen müsste. In diesem Szenario wird nun eine Ausnahme ausgelöst, so wie sie bereits ausgelöst wurde, wenn die Option Connection.execution_options.stream_results mit der Methode AsyncConnection.execute() verwendet wurde.

  Zusätzlich wird zur Verbesserung der Stabilität bei zustandsabhängigen Datenbanktreibern wie asyncmy der Cursor geschlossen, wenn dieser Fehlerzustand auftritt; zuvor geriet bei der asyncmy-Dialekt die Verbindung in einen ungültigen Zustand mit verbleibenden, nicht verbrauchten serverseitigen Ergebnissen.

  Referenzen: #7667

postgresql

• [postgresql] [usecase]

  Compiler-Unterstützung für die PostgreSQL-Phrase NOT VALID hinzugefügt, wenn DDL für die Schema-Konstrukte CheckConstraint, ForeignKeyConstraint und ForeignKey gerendert wird. Pull Request von Gilbert Gilb.

  Siehe auch

  PostgreSQL Constraint Options

  Referenzen: #7600

mysql

• [mysql] [bug] [regression]

  Behobene Regression, die durch #7518 verursacht wurde, bei der die Änderung der Syntax „SHOW VARIABLES“ zu „SELECT @@“ die Kompatibilität mit MySQL-Versionen älter als 5.6, einschließlich früher 5.0-Releases, brach. Obwohl dies sehr alte MySQL-Versionen sind, war eine Änderung der Kompatibilität nicht geplant, sodass nun eine versionsspezifische Logik wiederhergestellt wurde, um für MySQL-Serverversionen < 5.6 auf „SHOW VARIABLES“ zurückzufallen.

  Referenzen: #7518

mariadb

• [mariadb] [bug] [regression]

  Behobene Regression im mariadbconnector-Dialekt ab mariadb connector 1.0.10, bei der die DBAPI cursor.lastrowid nicht mehr vorab puffert, was zu Fehlern beim Einfügen von Objekten mit dem ORM führt und die Nichtverfügbarkeit des Attributs CursorResult.inserted_primary_key verursacht. Der Dialekt holt diesen Wert nun proaktiv für Situationen ab, in denen er zutrifft.

  Referenzen: #7738

sqlite

• [sqlite] [usecase]

  Unterstützung für die Reflexion von SQLite Inline-Unique-Constraints hinzugefügt, bei denen die Spaltennamen mit SQLite „Escape-Anführungszeichen“ [] oder ` formatiert sind, die von der Datenbank beim Erzeugen des Spaltennamens verworfen werden.

  Referenzen: #7736

• [sqlite] [bug]

  Behobenes Problem, bei dem die Reflexion von SQLite-Unique-Constraints eine Spalte-Inline-UNIQUE-Constraint nicht erkannte, wenn der Spaltenname einen Unterstrich enthielt.

  Referenzen: #7736

oracle

• [oracle] [bug]

  Behobenes Problem im Oracle-Dialekt, bei dem die Verwendung eines Spaltennamens, der bei der Angabe als gebundener Parameter Anführungszeichen erfordert, wie z. B. "_id", einen von Python generierten Standardwert nicht korrekt verfolgte, da das Rewriting des gebundenen Parameters diesen Wert verpasste, was zu einem Oracle-Fehler führte.

  Referenzen: #7676

• [oracle] [bug] [regression]

  Unterstützung für das Parsen von „DPI“-Fehlercodes aus cx_Oracle-Ausnahmeobjekten wie DPI-1080 und DPI-1010 hinzugefügt, die beide ab cx_Oracle 8.3 einen Trennungsszenario anzeigen.

  Referenzen: #7748

tests

• [tests] [bug]

  Verbesserungen an der Integration der Testsuite mit pytest, sodass das „warnings“-Plugin, wenn es manuell aktiviert ist, die Testsuite nicht stört, sodass Dritte das warnings-Plugin aktivieren oder den -W-Parameter nutzen können und die Testsuite von SQLAlchemy weiterhin erfolgreich durchläuft. Außerdem wurde die Erkennung des „pytest-xdist“-Plugins modernisiert, sodass Plugins global mit PYTEST_DISABLE_PLUGIN_AUTOLOAD=1 deaktiviert werden können, ohne die Testsuite zu brechen, wenn xdist noch installiert ist. Warnungsfilter, die Deprecation Warnings zu Fehlern hochstufen, sind nun auf SQLAlchemy-spezifische Warnungen oder innerhalb von SQLAlchemy-spezifischen Quellen für allgemeine Python-Deprecation Warnings beschränkt, sodass nicht-SQLAlchemy-Deprecation Warnings, die von pytest-Plugins ausgegeben werden, die Testsuite ebenfalls nicht beeinträchtigen sollten.

  Referenzen: #7599

• [tests] [bug]

  Korrekturen an der Standard-pytest-Konfiguration bezüglich der Test-Discovery wurden vorgenommen, um ein Problem zu beheben, bei dem die Testsuite Warnungen nicht korrekt konfigurierte und versuchte, Beispiel-Suiten als Tests zu laden, im spezifischen Fall, bei dem der SQLAlchemy-Checkout in einem absoluten Pfad lag, der ein übergeordnetes Verzeichnis namens „test“ hatte.

  Referenzen: #7045

1.4.31

Veröffentlicht: 20. Januar 2022

orm

• [orm] [bug]

  Behobenes Problem in Session.bulk_save_objects(), bei dem die Sortierung, die stattfindet, wenn der Parameter preserve_order auf False gesetzt ist, teilweise auf Mapper-Objekte sortierte, was in Python 3.11 abgelehnt wird.

  Referenzen: #7591

postgresql

• [postgresql] [bug] [regression]

  Behobene Regression, bei der die Änderung in #7148 zur Reparatur der ENUM-Behandlung in PostgreSQL den Anwendungsfall eines leeren ARRAY von ENUM brach, was verhinderte, dass Zeilen, die ein leeres Array enthielten, beim Abrufen von Ergebnissen korrekt verarbeitet wurden.

  Referenzen: #7590

mysql

• [mysql] [bug] [regression]

  Behobene Regression im asyncmy-Dialekt, verursacht durch #7567, bei der die Entfernung der PyMySQL-Abhängigkeit Binärspalten brach, da der asyncmy-Dialekt nicht ordnungsgemäß in CI-Tests einbezogen wurde.

  Referenzen: #7593

mssql

• [mssql]

  Unterstützung für FILESTREAM hinzugefügt, wenn VARBINARY(max) in MSSQL verwendet wird.

  Siehe auch

  VARBINARY.filestream

  Referenzen: #7243

1.4.30

Veröffentlicht: 19. Januar 2022

orm

• [orm] [bug]

  Behobenes Problem bei der Joined-Inheritance-Ladung zusätzlicher Attribute bei tiefer Mehrfacherbenung, bei der eine dazwischenliegende Tabelle ohne Spalten nicht in die verknüpften Tabellen aufgenommen wurde, stattdessen wurden diese Tabellen mit ihren Primärschlüssel-Identifikatoren verknüpft. Obwohl dies in Ordnung ist, führte es in 1.4 zu einer Warnung des Cartesian-Product-Compilers. Die Logik wurde geändert, sodass diese dazwischenliegenden Tabellen unabhängig davon einbezogen werden. Obwohl dies zusätzliche Tabellen in die Abfrage aufnimmt, die technisch nicht notwendig sind, tritt dies nur für den sehr ungewöhnlichen Fall von tiefer 3+ Level-Vererbung mit dazwischenliegenden Tabellen auf, die keine Nicht-Primärschlüssel-Spalten haben, sodass die potenzielle Leistungsauswirkung voraussichtlich vernachlässigbar ist.

  Referenzen: #7507

• [orm] [bug]

  Behobenes Problem, bei dem der Aufruf von registry.map_imperatively() mehr als einmal für dieselbe Klasse eine unerwartete Fehlermeldung erzeugte, anstatt einer informativen Fehlermeldung, dass die Zielklasse bereits gemappt ist. Dieses Verhalten unterschied sich von dem der Funktion mapper(), die bereits eine informative Meldung ausgibt.

  Referenzen: #7579

• [orm] [bug] [asyncio]

  Fehlende Methode AsyncSession.invalidate() zur Klasse AsyncSession hinzugefügt.

  Referenzen: #7524

• [orm] [bug] [regression]

  Behobene Regression, die in 1.4.23 auftrat und dazu führen konnte, dass Loader-Optionen in einigen Fällen falsch behandelt wurden, insbesondere bei der Verwendung von Joined-Table-Inheritance in Kombination mit der Option polymorphic_load="selectin" sowie Relationship-Lazy-Loading, was zu einem TypeError führte.

  Referenzen: #7557

• [orm] [bug] [regression]

  Behobene ORM-Regression, bei der der Aufruf der Funktion aliased() gegen einen vorhandenen aliased()-Konstrukt fehlschlug, korrekten SQL zu erzeugen, wenn das vorhandene Konstrukt gegen eine feste Tabelle gerichtet war. Die Korrektur erlaubt, dass das ursprüngliche aliased()-Konstrukt ignoriert wird, wenn es nur gegen eine Tabelle gerichtet war, die nun ersetzt wird. Es ermöglicht auch ein korrektes Verhalten beim Erstellen eines aliased() ohne wählbares Argument gegen ein aliased(), das gegen eine Unterabfrage gerichtet ist, um ein Alias dieser Unterabfrage zu erstellen (d. h. ihren Namen zu ändern).

  Das Verschachtelungsverhalten von aliased() bleibt für den Fall bestehen, dass das äußere aliased()-Objekt gegen eine Unterabfrage gerichtet ist, die wiederum auf das innere aliased()-Objekt verweist. Dies ist eine relativ neue Funktion von 1.4, die Anwendungsfälle unterstützt, die zuvor von der veralteten Methode Query.from_self() bedient wurden.

  Referenzen: #7576

• [orm] [bug]

  Behobenes Problem, bei dem die Methode Select.correlate_except(), wenn sie entweder mit dem Wert None oder ohne Argumente übergeben wurde, keine Elemente korrelierte, wenn sie in einem ORM-Kontext verwendet wurde (d. h. beim Übergeben von ORM-Entitäten als FROM-Klauseln), anstatt alle FROM-Elemente als „korreliert“ zu betrachten, wie es bei der Verwendung von Core-only-Konstrukten der Fall ist.

  Referenzen: #7514

• [orm] [bug] [regression]

  Behobene Regression von 1.3, bei der die „subqueryload“-Loader-Strategie mit einem Stack-Trace fehlschlug, wenn sie gegen eine Abfrage verwendet wurde, die Query.from_statement() oder Select.from_statement() verwendete. Da subqueryload die ursprüngliche Anweisung ändern muss, ist sie mit dem „from_statement“-Anwendungsfall nicht kompatibel, insbesondere für Anweisungen, die gegen den text()-Konstrukt gerichtet sind. Das Verhalten ist nun dem von 1.3 und früher gleich, d. h. die Loader-Strategie wird für solche Anweisungen stillschweigend herabgestuft und nicht verwendet, wobei normalerweise auf die Verwendung der Lazyload-Strategie zurückgegriffen wird.

  Referenzen: #7505

sql

• [sql] [bug] [postgresql]

  Zusätzliche Regel zum System hinzugefügt, das TypeEngine-Implementierungen aus Python-Literalen bestimmt, um eine zweite Anpassungsstufe des Typs anzuwenden, sodass ein Python-Datetime mit oder ohne Zeitzoneninformation den Parameter timezone=True auf dem zurückgegebenen DateTime-Objekt sowie auf Time setzen kann. Dies hilft bei einigen Roundtrip-Szenarien auf typsensitiven PostgreSQL-Dialekten wie asyncpg und psycopg3 (nur 2.0).

  Referenzen: #7537

• [sql] [bug]

  Informative Fehlermeldung hinzugefügt, wenn ein Methodenobjekt an einen SQL-Konstrukt übergeben wird. Zuvor wurden solche aufrufbaren Objekte, was ein häufiger Tippfehler bei der Arbeit mit methodenverketteten SQL-Konstrukten ist, als „lambda SQL“-Ziele interpretiert, die zur Kompilierungszeit aufgerufen werden, was zu stillen Fehlern führte. Da diese Funktion nicht für Methoden vorgesehen war, werden Methodenobjekte nun abgelehnt.

  Referenzen: #7032

mypy

• [mypy] [bug]

  Behobener Mypy-Crash bei der Ausführung im Daemon-Modus, der durch ein fehlendes Attribut auf einer internen mypy Var-Instanz verursacht wurde.

  Referenzen: #7321

asyncio

• [asyncio] [usecase]

  Neue Methode AdaptedConnection.run_async() zur DBAPI-Verbindungsschnittstelle für asyncio-Treiber hinzugefügt. Diese ermöglicht, Methoden direkt gegen die zugrunde liegende „Treiber“-Verbindung in einer Sync-Funktion aufzurufen, in der das Schlüsselwort await nicht verwendet werden kann, z. B. in SQLAlchemy-Event-Handler-Funktionen. Die Methode ist analog zur Methode AsyncConnection.run_sync(), die Async-Aufrufe in Sync-Aufrufe übersetzt. Die Methode ist nützlich für Dinge wie Connection-Pool-On-Connect-Handler, die beim Erstellen der Verbindung aufrufbare Methoden auf der Treiberverbindung aufrufen müssen.

  Siehe auch

  Verwendung von nur awaitable Treiber-Methoden im Connection Pool und anderen Events

  Referenzen: #7580

postgresql

• [postgresql] [usecase]

  Zeichenketten-Rendering für den UUID-Datentyp hinzugefügt, sodass das Stringifizieren einer Anweisung mit „literal_binds“, die diesen Typ verwendet, einen geeigneten Zeichenkettenwert für das PostgreSQL-Backend rendert. Pull Request von José Duarte.

  Referenzen: #7561

• [postgresql] [bug] [asyncpg]

  Verbesserte Unterstützung für die asyncpg-Verarbeitung von TIME WITH TIMEZONE, die noch nicht vollständig implementiert war.

  Referenzen: #7537

• [postgresql] [bug] [mssql] [reflection]

  Behobene Reflexion von Covering Indexes, um include_columns als Teil des Eintrags dialect_options im reflektierten Indexwörterbuch zu melden, wodurch Roundtrips von Reflexion->Erstellung vollständig werden. Eingeschlossene Spalten sind weiterhin aus Kompatibilitätsgründen unter dem Schlüssel include_columns vorhanden.

  Referenzen: #7382

• [postgresql] [bug]

  Korrigierte Verarbeitung von Arrays von Enum-Werten, die Escape-Zeichen erfordern.

  Referenzen: #7418

mysql

• [mysql] [change]

  Ersetzt die Anweisung SHOW VARIABLES LIKE durch das äquivalente SELECT @@variable in den MySQL- und MariaDB-Dialektinitialisierungen. Dies sollte Mutex-Konflikte vermeiden, die durch SHOW VARIABLES verursacht werden, und die Initialisierungsleistung verbessern.

  Referenzen: #7518

• [mysql] [bug]

  Entfernte unnötige Abhängigkeit von PyMySQL aus dem asyncmy-Dialekt. Pull Request von long2ice.

  Referenzen: #7567

1.4.29

Veröffentlicht: 22. Dezember 2021

orm

• [orm] [usecase]

  Parameter Session.get.execution_options hinzugefügt, der zuvor in der Methode Session.get() fehlte.

  Referenzen: #7410

• [orm] [bug]

  Behobenes Problem in der neuen Methode „loader criteria“ PropComparator.and_(), bei der die Verwendung mit einer Loader-Strategie wie selectinload() gegen eine Spalte, die Mitglied der .c.-Sammlung eines Unterabfrageobjekts war, wobei die Unterabfrage dynamisch zur FROM-Klausel der Anweisung hinzugefügt würde, zu veralteten Parameterwerten innerhalb der Unterabfrage im SQL-Anweisungs-Cache führen würde, da der von der Loader-Strategie verwendete Prozess zum Ersetzen der Parameter zur Ausführungszeit die Unterabfrage in dieser Form nicht berücksichtigen würde.

  Referenzen: #7489

• [orm] [bug]

  Behobener Rekursionsüberlauf, der bei der ORM-Anweisungskomprimierung auftreten konnte, wenn entweder das Feature with_loader_criteria() oder die Methode PropComparator.and_() innerhalb einer Loader-Strategie in Verbindung mit einer Unterabfrage verwendet wurde, die auf dieselbe Entität verwies, die durch die Kriterienoption geändert oder durch die Loader-Strategie geladen wurde. Eine Prüfung auf rekursives Auftreten derselben Loader-Kriterienoption wurde hinzugefügt, um dieses Szenario zu berücksichtigen.

  Referenzen: #7491

• [orm] [bug] [mypy]

  Behobenes Problem, bei dem die Methode __class_getitem__() der generierten deklarativen Basisklasse von as_declarative() zu unzugänglichen Klassenattributen wie __table__ führte, in Fällen, in denen eine Generic[T]-Style-Typdeklaration in der Klassenhierarchie verwendet wurde. Dies ist eine Fortsetzung der grundlegenden Hinzufügung von __class_getitem__() in #7368. Pull Request von Kai Mueller.

  Referenzen: #7368, #7462

• [orm] [bug] [regression]

  Behobenes Caching-bezogenes Problem, bei dem die Verwendung einer Loader-Option der Form lazyload(aliased(A).bs).joinedload(B.cs) dazu führte, dass das joinedload bei nachfolgenden Ausführungen der gecachten Abfrage nicht aufgerufen wurde, aufgrund einer Diskrepanz für die Optionen / Objektpfade, die auf die für eine Abfrage mit einer führenden Entität geladenen Objekte angewendet wurden, die aliased() verwendete.

  Referenzen: #7447

engine

• [engine] [bug]

  Korrigierte Fehlermeldung für den AttributeError, der ausgelöst wird, wenn versucht wird, auf ein Attribut der Row-Klasse zu schreiben, die unveränderlich ist. Die vorherige Meldung behauptete, die Spalte existiere nicht, was irreführend war.

  Referenzen: #7432

• [engine] [bug] [regression]

  Behobene Regression in der Funktion make_url() zum Parsen von URL-Zeichenketten, bei der das Parsen der Abfragezeichenkette zu einem Rekursionsüberlauf führte, wenn eine Python 2 u''-Zeichenkette verwendet wurde.

  Referenzen: #7446

mypy

• [mypy] [bug]

  Behobene mypy-Regression, bei der die Veröffentlichung von mypy 0.930 zusätzliche interne Prüfungen für das Format von „named types“ hinzugefügt hatte, die verlangten, dass sie vollständig qualifiziert und lokalisierbar seien. Dies brach das mypy-Plugin für SQLAlchemy und löste eine Assertion-Fehlermeldung aus, da Symbole wie __builtins__ und andere nicht lokalisierbare oder nicht qualifizierte Namen verwendet wurden, die zuvor keine Assertionen ausgelöst hatten.

  Referenzen: #7496

asyncio

• [asyncio] [usecase]

  Neue Funktion async_engine_config() hinzugefügt, um eine async-Engine aus einem Konfigurationswörterbuch zu erstellen. Diese verhält sich ansonsten gleich wie engine_from_config().

  Referenzen: #7301

mariadb

• [mariadb] [bug]

  Korrigierte die Fehlerklassen, die für die „is_disconnect“-Prüfung für das mariadbconnector-Dialekt untersucht wurden. Dies schlug bei Trennungen fehl, die aufgrund gängiger MySQL/MariaDB-Fehlercodes wie 2006 auftraten. Die DBAPI verwendet derzeit anscheinend die Ausnahme-Klasse mariadb.InterfaceError für Trennungsfehler wie Fehlercode 2006, die zur Liste der geprüften Klassen hinzugefügt wurde.

  Referenzen: #7457

tests

• [tests] [bug] [regression]

  Behob eine Regression in der Testsuite, bei der der Test CompareAndCopyTest::test_all_present auf einigen Plattformen aufgrund zusätzlicher erkannter Testartefakte fehlschlug. Pull-Request freundlicherweise von Nils Philippsen.

  Referenzen: #7450

1.4.28

Veröffentlicht: 9. Dezember 2021

platform

• [platform] [bug]

  Python 3.10 hat „distutils“ zugunsten der expliziten Verwendung von „setuptools“ in PEP 632 als veraltet erklärt; SQLAlchemy’s setup.py hat die Importe entsprechend ersetzt. Da setuptools selbst jedoch erst kürzlich die in PEP 632 erwähnten Ersatzsymbole ab November 2021 in Version 59.0.1 hinzugefügt hat, enthält setup.py immer noch Fallback-Importe für distutils, da SQLAlchemy 1.4 derzeit keine strenge Anforderung an die Versionierung von setuptools hat. SQLAlchemy 2.0 wird voraussichtlich ein vollständiges PEP 517 Installationslayout verwenden, das die entsprechende setuptools-Versionierung im Voraus angibt.

  Referenzen: #7311

orm

• [orm] [bug] [ext]

  Behob ein Problem, bei dem das interne Klonen, das von der Methode PropComparator.any() für eine relationship() verwendet wurde, wenn die zugehörige Klasse auch ORM-polymorphe Ladung nutzt, fehlschlug, wenn eine hybride Eigenschaft auf der zugehörigen, polymorphen Klasse innerhalb der Kriterien für die any()-Operation verwendet wurde.

  Referenzen: #7425

• [orm] [bug] [mypy]

  Behob ein Problem, bei dem der Dekorator as_declarative() und ähnliche Funktionen, die zur Erstellung der deklarativen Basisklasse verwendet werden, die Methode __class_getitem__() nicht von einer gegebenen Oberklasse kopierten, was die Verwendung von PEP 484-Generika in Verbindung mit der Base-Klasse verhinderte. Pull-Request freundlicherweise von Kai Mueller.

  Referenzen: #7368

• [orm] [bug] [regression]

  Behob eine ORM-Regression, bei der das neue Verhalten „eager loaders run on unexpire“, das in #1763 hinzugefügt wurde, zu unangemessen ausgelösten Loader-Optionenfehlern führte. Dies geschah in Fällen, in denen eine einzelne Query oder Select verwendet wurde, um mehrere Arten von Entitäten zu laden, zusammen mit Loader-Optionen, die nur für eine dieser Arten von Entitäten gelten, wie z. B. ein joinedload(). Später wurden die Objekte aus der Ablaufzeit neu erstellt, wobei die Loader-Optionen auf den falschen Objekttyp angewendet wurden und dann eine Ausnahme ausgelöst wurde. Die Prüfung auf diese Nichtübereinstimmung umgeht nun das Auslösen eines Fehlers für diesen Fall.

  Referenzen: #7318

• [orm] [bug]

  Benutzerdefinierte ORM-Optionen, wie sie im dogpile.caching-Beispiel illustriert werden und UserDefinedOption unterklassen, werden per Definition bei jeder Anweisungsausführung behandelt und müssen nicht als Teil des Cache-Schlüssels für die Anweisung betrachtet werden. Das Caching der Basis-Klasse ExecutableOption wurde geändert, sodass sie nicht mehr direkt eine HasCacheKey-Unterklasse ist. Dadurch hat die Anwesenheit benutzerdefinierter Options-Objekte nicht mehr den unerwünschten Nebeneffekt, das Caching von Anweisungen zu deaktivieren. Nur ORM-spezifische Lade- und Kriterien-Optionen, die alle intern zu SQLAlchemy gehören, nehmen nun am Caching-System teil.

  Referenzen: #7394

• [orm] [bug]

  Behob ein Problem, bei dem Zuordnungen, die synonym() und möglicherweise andere Arten von „Proxy“-Attributen verwendeten, nicht in allen Fällen erfolgreich einen Cache-Schlüssel für ihre SQL-Anweisungen generierten, was zu einer Leistungsminderung bei diesen Anweisungen führte.

  Referenzen: #7394

• [orm] [bug]

  Behob ein Problem, bei dem eine mit relationship() zugeordnete Liste in eine Endlosschleife geriet, wenn sie sich selbst inplace hinzugefügt wurde, d. h. wenn der Operator += verwendet wurde, sowie wenn .extend() dieselbe Liste erhielt.

  Referenzen: #7389

• [orm] [bug]

  Behob ein Problem, bei dem eine Ausnahme auftrat, wenn die Session die Verbindung innerhalb der Methode Session.commit() schloss, wenn ein Kontextmanager für Session.begin() verwendet wurde. Es wurde ein Rollback versucht, der nicht möglich war, da sich die Session zwischen dem Commit der Transaktion und der Rückgabe der Verbindung an den Pool befand, wodurch die Ausnahme „this sessiontransaction is in the committed state“ ausgelöst wurde. Diese Ausnahme kann meist in einem asyncio-Kontext auftreten, in dem CancelledError ausgelöst werden kann.

  Referenzen: #7388

• [orm] [deprecated]

  Eine undokumentierte Loader-Option-Syntax ".*" wurde als veraltet markiert. Diese scheint sich nicht von der Übergabe eines einzelnen Sternchens zu unterscheiden und gibt eine Verwarnung aus, wenn sie verwendet wird. Diese Syntax war möglicherweise für etwas gedacht, aber es gibt derzeit keinen Bedarf dafür.

  Referenzen: #4390

engine

• [engine] [usecase]

  Unterstützung für copy() und deepcopy() wurde zur URL-Klasse hinzugefügt. Pull-Request freundlicherweise von Tom Ritchford.

  Referenzen: #7400

sql

• [sql] [usecase]

  „Compound select“-Methoden wie Select.union(), Select.intersect_all() usw. akzeptieren jetzt *other als Argument anstelle von other, um die Kombination mehrerer zusätzlicher SELECTs mit der übergeordneten Anweisung gleichzeitig zu ermöglichen. Insbesondere die Änderung, wie sie auf CTE.union() und CTE.union_all() angewendet wird, ermöglicht nun die Erstellung einer sogenannten „nicht-linearen CTE“ mit der CTE-Konstruktion, während es zuvor keine Möglichkeit gab, mehr als zwei CTE-Unterelemente in einem UNION zusammenzufassen und dabei die CTE korrekt rekursiv aufzurufen. Pull-Request freundlicherweise von Eric Masseran.

  Referenzen: #7259

• [sql] [usecase]

  Unterstützung für mehrere Klausel-Elemente in der Methode Exists.where(), wodurch die API mit derjenigen vereinheitlicht wird, die von einem normalen select()-Konstruktion bereitgestellt wird.

  Referenzen: #7386

• [sql] [bug] [regression]

  Das Attribut TypeDecorator.cache_ok und die entsprechende Warnmeldung, falls dieses Flag nicht definiert ist, wurden auf UserDefinedType ausgedehnt. Dieses Verhalten wurde ursprünglich für TypeDecorator als Teil von #6436 etabliert. Dies geschah durch die Verallgemeinerung des Flags und der zugehörigen Caching-Logik auf eine neue gemeinsame Basis für diese beiden Typen, ExternalType, um UserDefinedType.cache_ok zu erstellen.

  Die Änderung bedeutet, dass jeder aktuelle UserDefinedType nun dazu führt, dass das Caching von SQL-Anweisungen für Anweisungen, die den Datentyp verwenden, nicht mehr stattfindet, zusammen mit einer Warnung, es sei denn, die Klasse definiert das Flag UserDefinedType.cache_ok als True. Wenn der Datentyp keinen deterministischen, hashbaren Cache-Schlüssel aus seinen Argumenten bilden kann, kann das Attribut auf False gesetzt werden, was das Caching weiterhin deaktiviert, aber die Warnung unterdrückt. Insbesondere benutzerdefinierte Datentypen, die derzeit in Paketen wie SQLAlchemy-utils verwendet werden, müssen dieses Flag implementieren. Das Problem wurde als Ergebnis eines SQLAlchemy-utils-Datentyps beobachtet, der derzeit nicht cachbar ist.

  Siehe auch

  ExternalType.cache_ok

  Referenzen: #7319

• [sql] [bug]

  Benutzerdefinierte SQL-Elemente, Drittanbieter-Dialekte, benutzerdefinierte oder Drittanbieter-Datentypen generieren konsistente Warnungen, wenn sie sich nicht klar für oder gegen das Caching von SQL-Anweisungen entscheiden, was durch das Setzen der entsprechenden Attribute auf jedem Klassentyp erreicht wird. Die Warnung verweist auf Dokumentationsabschnitte, die den geeigneten Ansatz für jeden Objekttyp angeben, um das Caching zu aktivieren.

  Referenzen: #7394

• [sql] [bug]

  Behob fehlende Caching-Direktiven für einige weniger verwendete Klassen in SQL Core, die dazu führten, dass für Elemente, die diese verwendeten, [no key] protokolliert wurde.

  Referenzen: #7394

mypy

• [mypy] [bug]

  Behob einen Mypy-Absturz, der auftrat, wenn das Mypy-Plugin gegen Code verwendet wurde, der declared_attr-Methoden für nicht zugeordnete Namen wie __mapper_args__, __table_args__ oder andere Dunder-Namen verwendete. Das Plugin versuchte, diese als zugeordnete Attribute zu interpretieren, die dann falsch behandelt wurden. Als Teil dieser Änderung wird die dekorierte Funktion weiterhin vom Plugin in eine generische Zuweisungsanweisung umgewandelt (z. B. __mapper_args__: Any), sodass die Argumentsignatur weiterhin wie bei jeder anderen @classmethod annotiert werden kann, ohne dass Mypy sich über den falschen Argumenttyp für eine Methode beschwert, die nicht explizit @classmethod ist.

  Referenzen: #7321

postgresql

• [postgresql] [bug]

  Behob fehlende Caching-Direktiven für hstore- und array-Konstruktionen, die dazu führten, dass für diese Elemente [no key] protokolliert wurde.

  Referenzen: #7394

tests

• [tests] [bug]

  Implementierte Unterstützung dafür, dass die Testsuite unter Pytest 7 korrekt ausgeführt wird. Zuvor wurde nur Pytest 6.x für Python 3 unterstützt, jedoch war die Version in tox.ini nicht nach oben begrenzt. Pytest ist in tox.ini nicht auf eine niedrigere Version als 8 beschränkt, damit SQLAlchemy-Versionen, die mit der aktuellen Codebasis veröffentlicht werden, ohne Änderungen an der Umgebung unter tox getestet werden können. Vielen Dank an die Pytest-Entwickler für ihre Hilfe bei diesem Problem.

1.4.27

Veröffentlicht: 11. November 2021

orm

• [orm] [bug]

  Behob einen Fehler in der Funktion „relationship to aliased class“, die in Relationship to Aliased Class eingeführt wurde. Zuvor war es nicht möglich, eine Loader-Strategie-Option zu erstellen, die auf ein Attribut auf dem Ziel mit dem aliased()-Konstrukt direkt in einer zweiten Loader-Option zielte, wie z. B. selectinload(A.aliased_bs).joinedload(aliased_b.cs), ohne explizit mit PropComparator.of_type() auf dem vorhergehenden Element des Pfades zu qualifizieren. Zusätzlich wurde das direkte Zielen auf die nicht-aliierte Klasse akzeptiert (unangemessen), schlug aber stillschweigend fehl, wie z. B. selectinload(A.aliased_bs).joinedload(B.cs). Dies löst nun einen Fehler aus, der auf die Typen-Nichtübereinstimmung verweist.

  Referenzen: #7224

• [orm] [bug]

  Alle Result-Objekte lösen nun konsistent ResourceClosedError aus, wenn sie nach einem Hard Close verwendet werden. Dies schließt den „Hard Close“ ein, der nach dem Aufruf von „Single Row or Value“-Methoden wie Result.first() und Result.scalar() auftritt. Dies war bereits das Verhalten der gebräuchlichsten Klasse von Ergebnisobjekten, die für Core-Anweisungs-Ausführungen zurückgegeben wurden, d. h. die auf CursorResult basieren, sodass dieses Verhalten nicht neu ist. Die Änderung wurde jedoch erweitert, um die ORM-„Filterungs“-Ergebnisobjekte, die bei Verwendung von ORM-Abfragen im 2.0-Stil zurückgegeben werden, korrekt zu unterstützen. Diese verhielten sich zuvor im „Soft Close“-Stil, indem sie leere Ergebnisse zurückgaben, oder schlossen sich gar nicht „soft“ und lieferten weiterhin aus dem zugrunde liegenden Cursor.

  Als Teil dieser Änderung wurde Result.close() zur Basis Result-Klasse hinzugefügt und für die gefilterten Ergebnis-Implementierungen, die von der ORM verwendet werden, implementiert. Dies ermöglicht es, die Methode CursorResult.close() für den zugrunde liegenden CursorResult aufzurufen, wenn die Ausführungsoption yield_per verwendet wird, um einen serverseitigen Cursor zu schließen, bevor verbleibende ORM-Ergebnisse abgerufen wurden. Dies war bereits für Core-Ergebnis-Sets verfügbar, aber die Änderung macht es auch für 2.0-Stil ORM-Ergebnisse verfügbar.

  Referenzen: #7274

• [orm] [bug] [regression]

  Behob eine 1.4-Regression, bei der Query.filter_by() auf einer Query, die aus Query.union(), Query.from_self() oder ähnlichem erzeugt wurde, nicht korrekt funktionierte.

  Referenzen: #7239

• [orm] [bug]

  Behob ein Problem, bei dem das verzögerte polymorphe Laden von Attributen aus einer Joined-Table-Inheritance-Unterklasse das Attribut nicht korrekt populierte, wenn die Option load_only() verwendet wurde, um dieses Attribut ursprünglich auszuschließen. Dies geschah im Fall, dass load_only von einer Relationship-Loader-Option abstammte. Die Korrektur ermöglicht, dass andere gültige Optionen wie defer(..., raiseload=True) usw. weiterhin wie erwartet funktionieren.

  Referenzen: #7304

• [orm] [bug] [regression]

  Behob eine 1.4-Regression, bei der Query.filter_by() nicht korrekt funktionierte, wenn Query.join() mit einer Entität verbunden wurde, die PropComparator.of_type() verwendete, um eine aliasierte Version der Zielentität anzugeben. Das Problem gilt auch für zukünftige ORM-Abfragen, die mit select() konstruiert werden.

  Referenzen: #7244

engine

• [engine] [bug]

  Behob ein Problem im zukünftigen Connection-Objekt, bei dem die Methode Connection.execute() kein nicht-dict-Mapping-Objekt wie SQLAlchemy’s eigenes RowMapping oder ein anderes abc.collections.Mapping-Objekt als Parameter-Dictionary akzeptierte.

  Referenzen: #7291

• [engine] [bug] [regression]

  Behob eine Regression, bei der die Methode CursorResult.fetchmany() einen serverseitigen Cursor nicht automatisch schloss (d. h. wenn stream_results oder yield_per verwendet wurde, sowohl für Core- als auch für ORM-orientierte Ergebnisse), wenn die Ergebnisse vollständig erschöpft waren.

  Referenzen: #7274

• [engine] [bug]

  Behob ein Problem im zukünftigen Engine, bei dem der Aufruf von Engine.begin() und das Betreten des Kontextmanagers die Verbindung nicht schlossen, wenn die eigentliche BEGIN-Operation aus irgendeinem Grund fehlschlug, z. B. wenn ein Event-Handler eine Ausnahme auslöste. Dieser Anwendungsfall wurde für die zukünftige Version der Engine nicht getestet. Beachten Sie, dass die „zukünftigen“ Kontextmanager, die begin()-Blöcke in Core und ORM handhaben, die „BEGIN“-Operation erst ausführen, wenn die Kontextmanager tatsächlich betreten werden. Dies unterscheidet sich von der Legacy-Version, die die „BEGIN“-Operation im Voraus ausführt.

  Referenzen: #7272

sql

• [sql] [usecase]

  Die Klasse TupleType wurde dem obersten Import-Namespace sqlalchemy hinzugefügt.

• [sql] [bug] [regression]

  Behob eine Regression, bei der die Zeilenobjekte, die für ORM-Abfragen zurückgegeben wurden (jetzt die normalen Row-Objekte), vom Operator ColumnOperators.in_() nicht als Tupelwerte interpretiert wurden, die in einzelne gebundene Parameter aufgeteilt werden sollten. Stattdessen wurden sie als einzelne Werte an den Treiber übergeben, was zu Fehlern führte. Die Änderung am „expanding IN“-System berücksichtigt nun, dass der Ausdruck bereits vom Typ TupleType ist, und behandelt Werte entsprechend, wenn dies der Fall ist. Im seltenen Fall der Verwendung von „tuple-in“ mit einer untypisierten Anweisung, wie z. B. einer Textanweisung ohne Typisierungsinformationen, wird ein Tupelwert für Werte erkannt, die collections.abc.Sequence implementieren, aber keine str oder bytes sind, wie immer beim Testen auf Sequence.

  Referenzen: #7292

• [sql] [bug]

  Behobenes Problem, bei dem die Funktion zur Verwendung eines Zeichenfolgenlabels für die Sortierung oder Gruppierung, die unter Sortierung oder Gruppierung nach einem Label beschrieben ist, nicht korrekt funktionierte, wenn sie auf eine CTE-Konstruktion angewendet wurde, wenn die CTE in einer umschließenden Select-Anweisung eingebettet war, die selbst als Skalar-Subquery eingerichtet war.

  Referenzen: #7269

• [sql] [bug] [regression]

  Behobene Regression, bei der die text()-Konstruktion nicht mehr als Zielbedingung in der Liste "whens" innerhalb einer case()-Konstruktion akzeptiert wurde. Die Regression scheint mit dem Versuch zusammenzuhängen, bestimmte Arten von Literalwerten zu vermeiden, die hier als mehrdeutig betrachtet wurden. Es gibt jedoch keinen Grund, warum die Zielbedingungen nicht als offen interpretierte SQL-Ausdrücke behandelt werden sollten, genau wie überall sonst. Eine Zeichenfolge oder ein Tupel wird in einen gebundenen Parameter umgewandelt, wie es auch anderswo der Fall wäre.

  Referenzen: #7287

schema

• [schema] [bug]

  Behobenes Problem in Table, bei dem der Parameter Table.implicit_returning nicht korrekt berücksichtigt wurde, wenn er zusammen mit Table.extend_existing übergeben wurde, um eine vorhandene Table zu erweitern.

  Referenzen: #7295

postgresql

• [postgresql] [usecase] [asyncpg]

  Hinzugefügte überschreibbare Methoden PGDialect_asyncpg.setup_asyncpg_json_codec und PGDialect_asyncpg.setup_asyncpg_jsonb_codec, die die erforderliche Aufgabe der Registrierung von JSON/JSONB-Codecs für diese Datentypen bei Verwendung von asyncpg übernehmen. Die Änderung besteht darin, dass die Methoden als einzelne, überschreibbare Methoden ausgelagert wurden, um Drittanbieter-Dialekte zu unterstützen, die ändern oder deaktivieren müssen, wie diese spezifischen Codecs eingerichtet werden.

  Referenzen: #7284

• [postgresql] [bug] [asyncpg]

  Der asyncpg-Dialekt wurde geändert, um den Float-Typ an den PostgreSQL-Typ "float" anstelle von "numeric" zu binden, damit der Wert float(inf) unterstützt werden kann. Unterstützung für die Persistenz des "inf"-Werts wurde zur Testsuite hinzugefügt.

  Referenzen: #7283

• [postgresql] [pg8000]

  Verbesserte Array-Verarbeitung bei Verwendung von PostgreSQL mit dem pg8000-Dialekt.

  Referenzen: #7167

mysql

• [mysql] [bug] [mariadb]

  Die Liste der reservierten Wörter wurde in zwei separate Listen aufgeteilt, eine für MySQL und eine für MariaDB, damit diese abweichenden Wortmengen genauer verwaltet werden können. Der MySQL/MariaDB-Dialekt wurde angepasst, um zwischen diesen Listen zu wechseln, basierend auf der entweder explizit konfigurierten oder server-versionserkannten "MySQL" oder "MariaDB" Backend. Alle aktuellen reservierten Wörter bis MySQL 8 und aktuelle MariaDB-Versionen, einschließlich neu hinzugefügter Schlüsselwörter wie "lead", wurden hinzugefügt. Pull Request von Kevin Kirsche.

  Referenzen: #7167

• [mysql] [bug]

  Behobenes Problem in MySQL Insert.on_duplicate_key_update(), bei dem der falsche Spaltenname gerendert wurde, wenn ein Ausdruck in einem VALUES-Ausdruck verwendet wurde. Pull Request von Cristian Sabaila.

  Referenzen: #7281

mssql

• [mssql] [bug]

  Die Generierung von "post compile"-Symbolen durch den Compiler, einschließlich der für "expanding IN" sowie für die "schema translate map" verwendeten Symbole, wurde angepasst, sodass sie nicht mehr direkt auf einfachen, mit Klammern versehenen Zeichenfolgen mit Unterstrichen basieren. Dies widerspricht direkt dem SQL Server-Format der Anführungszeichen, das ebenfalls Klammern verwendet und zu falsch positiven Übereinstimmungen führt, wenn der Compiler "post compile" und "schema translate" Symbole ersetzt. Das Problem führte zu leicht reproduzierbaren Beispielen sowohl mit der Methode Inspector.get_schema_names() in Verbindung mit der Funktion Connection.execution_options.schema_translate_map als auch im unwahrscheinlichen Fall, dass ein Symbol, das mit dem internen Namen "POSTCOMPILE" kollidiert, mit einer Funktion wie "expanding in" verwendet wurde.

  Referenzen: #7300

1.4.26

Veröffentlicht: 19. Oktober 2021

orm

• [orm] [bug]

  Verbesserte Fehlermeldung bei der Konfiguration einer Abbildung mit Joined-Table-Inheritance, bei der die beiden Tabellen entweder keine Fremdschlüsselbeziehungen eingerichtet haben oder mehrere Fremdschlüsselbeziehungen eingerichtet haben. Die Meldung ist jetzt ORM-spezifisch und enthält den Hinweis, dass der Parameter Mapper.inherit_condition erforderlich sein kann, insbesondere im Fall mehrdeutiger Fremdschlüssel.

• [orm] [bug]

  Behobenes Problem mit der Funktion with_loader_criteria(), bei der ON-Kriterien nicht zu einem JOIN für eine Abfrage der Form select(A).join(B) hinzugefügt wurden, die ein Ziel angibt, während eine implizite ON-Klausel verwendet wurde.

  Referenzen: #7189

• [orm] [bug]

  Behobener Fehler, bei dem das ORM-„Plugin“, das für Funktionen wie with_loader_criteria() erforderlich ist, nicht auf eine select()-Anweisung angewendet wurde, die aus einem ORM-Spaltenausdruck abfragte, wenn der Modifikator ColumnElement.label() verwendet wurde.

  Referenzen: #7205

• [orm] [bug]

  Hinzugefügte fehlende Methoden zu scoped_session und async_scoped_session(), die in #6991 hinzugefügt wurden.

  Referenzen: #7103

• [orm] [bug]

  Eine zusätzliche Ebene von Warnmeldungen wurde der Funktionalität von Query.join() und der ORM-Version von Select.join() hinzugefügt. An einigen Stellen, an denen immer noch "automatisches Aliasing" auftritt, wird nun darauf hingewiesen, dass dies ein zu vermeidendes Muster ist, hauptsächlich im Bereich der Joined-Table-Inheritance, wo Klassen, die gemeinsame Basistabellen teilen, ohne explizite Aliase miteinander verbunden werden. Ein Fall löst eine Legacy-Warnung für ein nicht empfohlenes Muster aus, der andere Fall ist vollständig veraltet.

  Das automatische Aliasing innerhalb von ORM join(), das für überlappende Abbildungstabellen auftritt, funktioniert nicht konsistent mit allen APIs wie contains_eager(). Anstatt weiterhin zu versuchen, diese Anwendungsfälle überall funktionieren zu lassen, ist die Ersetzung durch ein expliziteres Benutzermuster klarer, weniger fehleranfällig und vereinfacht die internen Abläufe von SQLAlchemy weiter.

  Die Warnungen enthalten Links zur Seite errors.rst, wo jedes Muster zusammen mit dem empfohlenen Muster zur Behebung demonstriert wird.

  Siehe auch

  Ein Alias wird automatisch für rohe Klausuleelemente generiert

  Ein Alias wird automatisch aufgrund überlappender Tabellen generiert

  Referenzen: #6972, #6974

• [orm] [bug]

  Behobener Fehler, bei dem das Iterieren eines Result von einer Session, nachdem diese Session geschlossen wurde, Objekte teilweise in einem ungültigen Zustand an diese Sitzung angehängt hätte. Es wird nun eine Ausnahme mit einem Link zur neuen Dokumentation ausgelöst, wenn ein **un-gepufferter** Ergebnis von einer geschlossenen Session oder einer Session.expunge_all()-Methode nach der Erzeugung dieses Result iteriert wird. Die Ausführungsoption prebuffer_rows, die automatisch von der asyncio-Erweiterung für clientseitige Ergebnissets verwendet wird, kann verwendet werden, um ein Result zu erzeugen, bei dem die ORM-Objekte vorab gepuffert werden. In diesem Fall erzeugt das Iterieren des Ergebnisses eine Reihe von getrennten Objekten.

  Siehe auch

  Objekt kann nicht in den 'persistenten' Zustand konvertiert werden, da diese Identitätszuordnung nicht mehr gültig ist.

  Referenzen: #7128

• [orm] [bug]

  In Bezug auf #7153 wurde ein Problem behoben, bei dem Ergebnisspalten-Lookups für "angepasste" SELECT-Anweisungen fehlschlugen, die für "konstante" Wertausdrücke, meistens den NULL-Ausdruck, abfragten. Dies geschah typischerweise bei Joined Eager Loading in Verbindung mit limit/offset. Dies war insgesamt eine Regression aufgrund von Problem #6259, das die gesamte "Anpassung" für Konstanten wie NULL, "true" und "false" beim Umschreiben von Ausdrücken in einer SQL-Anweisung entfernte. Dies brach jedoch den Fall, bei dem die gleiche Anpassungslogik verwendet wurde, um die Konstante für die Ergebniszielsetzung in einen beschrifteten Ausdruck aufzulösen.

  Referenzen: #7154

• [orm] [bug] [regression]

  Behobene Regression, bei der ORM-geladene Objekte nicht gepickelt werden konnten, wenn Loader-Optionen, die "*" verwendeten, in bestimmten Kombinationen genutzt wurden, wie z. B. die Kombination der joinedload() Loader-Strategie mit raiseload('*') von Unterelementen.

  Referenzen: #7134

• [orm] [bug] [regression]

  Behobene Regression, bei der die Verwendung eines hybrid_property-Attributs oder eines abgebildeten composite()-Attributs als Schlüssel, der an die Methode Update.values() für eine ORM-aktivierte Update-Anweisung übergeben wird, sowie bei Verwendung über die Legacy-Methode Query.update(), während der Kompilierungsphase der UPDATE-Anweisung für eingehende ORM/Hybrid/Composite-Werte verarbeitet wurde. Das bedeutete, dass in Fällen, in denen Caching stattfand, nachfolgende Aufrufe derselben Anweisung nicht mehr die korrekten Werte erhielten. Dies betraf nicht nur Hybride, die die Methode hybrid_property.update_expression() verwendeten, sondern jegliche Verwendung eines einfachen Hybrid-Attributs. Für Composite-Objekte verursachte das Problem stattdessen einen nicht wiederholbaren Cache-Schlüssel, der das Caching unterbrach und den Statement-Cache mit wiederholten Anweisungen füllen konnte.

  Die Update-Konstruktion verarbeitet nun die Verarbeitung von Schlüssel/Wert-Paaren, die an Update.values() und Update.ordered_values() übergeben werden, von vornherein, wenn die Konstruktion zuerst generiert wird, bevor der Cache-Schlüssel generiert wurde. Dadurch werden die Schlüssel/Wert-Paare jedes Mal verarbeitet und der Cache-Schlüssel wird anhand der einzelnen Spalten/Wert-Paare generiert, die letztendlich in der Anweisung verwendet werden.

  Referenzen: #7209

• [orm]

  Das Übergeben eines Query-Objekts an Session.execute() ist keine beabsichtigte Verwendung dieses Objekts und löst nun eine Deprecation-Warnung aus.

  Referenzen: #6284

examples

• [examples] [bug]

  Die Beispiele in examples/versioned_rows wurden repariert, um SQLAlchemy 1.4 APIs korrekt zu verwenden. Diese Beispiele wurden bei API-Änderungen übersehen, wie z. B. das Entfernen von "passive" aus Session.is_modified() und das Hinzufügen des SessionEvents.do_orm_execute() Event-Hooks.

  Referenzen: #7169

engine

• [engine] [bug]

  Behobenes Problem, bei dem die Deprecation-Warnung für den Konstruktor URL, die darauf hinweist, dass die Methode URL.create() verwendet werden sollte, nicht ausgegeben wurde, wenn eine vollständige Liste von sieben Positionsargumenten übergeben wurde. Zusätzlich wird die Validierung von URL-Argumenten nun durchgeführt, wenn der Konstruktor auf diese Weise aufgerufen wird, was zuvor übersprungen wurde.

  Referenzen: #7130

• [engine] [bug] [postgresql]

  Die Methode Inspector.reflect_table() unterstützt nun die Reflexion von Tabellen, die keine benutzerdefinierten Spalten haben. Dies ermöglicht MetaData.reflect(), die Reflexion auf Datenbanken mit solchen Tabellen ordnungsgemäß abzuschließen. Derzeit ist nur PostgreSQL dafür bekannt, eine solche Konstruktion unter den gängigen Datenbank-Backends zu unterstützen.

  Referenzen: #3247

• [engine] [bug]

  Implementierte korrekte __reduce__()-Methoden für alle SQLAlchemy-Ausnahmeobjekte, um sicherzustellen, dass sie saubere Roundtrips beim Pickeln unterstützen, da Ausnahmeobjekte oft für verschiedene Debugging-Tools serialisiert werden.

  Referenzen: #7077

sql

• [sql] [bug]

  Behobenes Problem, bei dem SQL-Abfragen mit der FunctionElement.within_group()-Konstruktion nicht gepickelt werden konnten, typischerweise bei Verwendung der Erweiterung sqlalchemy.ext.serializer, aber auch für allgemeines, generisches Pickling.

  Referenzen: #6520

• [sql] [bug]

  Behobenes Problem in der neuen HasCTE.cte.nesting-Parameter eingeführt mit #4123, bei dem eine rekursive CTE mit HasCTE.cte.recursive in typischer Kombination mit UNION nicht korrekt kompiliert werden konnte. Darüber hinaus werden einige Anpassungen vorgenommen, damit die CTE-Konstruktion einen korrekten Cache-Schlüssel erstellt. Pull Request von Eric Masseran.

  Referenzen: #4123

• [sql] [bug]

  Berücksichtigung des table.schema-Parameters, der an die table()-Konstruktion übergeben wird, sodass er beim Zugriff auf das Attribut TableClause.fullname berücksichtigt wird.

  Referenzen: #7061

• [sql] [bug]

  Behebung einer Inkonsistenz in den Funktionen/Methoden ColumnOperators.any_() / ColumnOperators.all_(), bei der das spezielle Verhalten dieser Funktionen, den Ausdruck zu "kehren", sodass der Ausdruck "ANY" / "ALL" immer auf der rechten Seite steht, nicht funktionierte, wenn der Vergleich gegen den None-Wert erfolgte. Das bedeutet, "column.any_() == None" sollte denselben SQL-Ausdruck erzeugen wie "null() == column.any_()". Es wurden weitere Dokumentationen hinzugefügt, um dies zu verdeutlichen, sowie Hinweise, dass any_()/all() im Allgemeinen die ARRAY-Versionen "any()" / "all()" übertreffen.

  Referenzen: #7140

• [sql] [bug] [regression]

  Behobenes Problem, bei dem das "expanding IN" mit Datentypen, die die Methode TypeEngine.bind_expression() verwenden, nicht korrekt funktionierte. Die Methode müsste auf jedes Element des IN-Ausdrucks angewendet werden und nicht auf den gesamten IN-Ausdruck selbst.

  Referenzen: #7177

• [sql] [bug]

  Die "Spalten-Disambiguierungs"-Logik, die neu in 1.4 ist und bei der wiederholte Ausdrücke eine "zusätzliche anonyme" Bezeichnung erhalten, wurde angepasst. Die Logik dedupliziert diese Bezeichnungen nun aggressiver, wenn das wiederholte Element jedes Mal dasselbe Python-Ausdrucksobjekt ist, wie es bei "Singleton"-Werten wie null() vorkommt. Dies basiert auf der Beobachtung, dass mindestens einige Datenbanken (z. B. MySQL, aber nicht SQLite) einen Fehler auslösen, wenn dieselbe Bezeichnung innerhalb einer Subquery wiederholt wird.

  Referenzen: #7153

mypy

• [mypy] [bug]

  Behobenes Problem im mypy-Plugin zur Verbesserung der Erkennung von Enum() SQL-Typen, die benutzerdefinierte Python-Enumerationsklassen enthalten. Pull Request von Hiroshi Ogawa.

  Referenzen: #6435

postgresql

• [postgresql] [bug]

  Eine "disconnect"-Bedingung für die Fehlermeldung "SSL SYSCALL error: Bad address", wie sie von psycopg2 gemeldet wird, wurde hinzugefügt. Pull Request von Zeke Brechtel.

  Referenzen: #5387

• [postgresql] [bug] [regression]

  Behobenes Problem, bei dem IN-Ausdrücke gegen eine Reihe von Array-Elementen, wie es mit PostgreSQL möglich ist, aufgrund mehrerer Probleme innerhalb des "expanding IN"-Features von SQLAlchemy Core, das in Version 1.4 standardisiert wurde, nicht korrekt funktionierten. Der psycopg2-Dialekt verwendet nun die Methode TypeEngine.bind_expression() mit ARRAY, um portabel die korrekten Casts auf Elemente anzuwenden. Der asyncpg-Dialekt war von diesem Problem nicht betroffen, da er Bind-Level-Casts auf Treiberebene anstelle auf Compiler-Ebene anwendet.

  Referenzen: #7177

mysql

• [mysql] [bug] [mariadb]

  Anpassungen, um die MariaDB 10.6-Serie zu unterstützen, einschließlich abwärtsinkompatibler Änderungen sowohl im mariadb-connector Python-Treiber (nur für SQLAlchemy 1.4 unterstützt) als auch in den nativen 10.6-Clientbibliotheken, die automatisch vom mysqlclient DBAPI verwendet werden (gilt für 1.3 und 1.4). Das Kodierungssymbol „utf8mb3“ wird jetzt von diesen Clientbibliotheken gemeldet, wenn die Kodierung als „utf8“ angegeben wird, was zu Nachschlage- und Kodierungsfehlern innerhalb der MySQL-Dialekt führt, der dieses Symbol nicht erwartet. Aktualisierungen sowohl der MySQL-Basisbibliothek, um diese Meldung von utf8mb3 zu unterstützen, als auch der Testsuite. Vielen Dank an Georg Richter für die Unterstützung.

  Diese Änderung wird auch **zurückportiert** auf: 1.3.25

  Referenzen: #7115, #7136

• [mysql] [bug]

  Fehler in der MySQL match()-Konstruktion behoben, bei der die Übergabe einer Klauselausdrucks wie bindparam() oder eines anderen SQL-Ausdrucks für den Parameter „against“ fehlschlug. Pull Request von Anton Kovalevich.

  Referenzen: #7144

• [mysql] [bug]

  Installationsproblem behoben, bei dem das Modul sqlalchemy.dialects.mysql nicht importierbar war, wenn „greenlet“ nicht installiert war.

  Referenzen: #7204

mssql

• [mssql] [usecase]

  Unterstützung für SQL Server Fremdschlüsseloptionen hinzugefügt, einschließlich „ON UPDATE“- und „ON DELETE“-Werten von „CASCADE“ und „SET NULL“.

• [mssql] [bug]

  Problem mit Inspector.get_foreign_keys() behoben, bei dem Fremdschlüssel weggelassen wurden, wenn sie auf einem eindeutigen Index anstatt einer eindeutigen Einschränkung basierten.

  Referenzen: #7160

• [mssql] [bug]

  Problem mit Inspector.has_table() behoben, bei dem False zurückgegeben wurde, wenn eine lokale temporäre Tabelle mit demselben Namen aus einer anderen Sitzung zuerst bei der Abfrage von tempdb zurückgegeben wurde. Dies ist eine Fortsetzung von #6910, der das Vorhandensein der temporären Tabelle nur in der alternativen Sitzung und nicht in der aktuellen behandelte.

  Referenzen: #7168

• [mssql] [bug] [regression]

  Fehler im SQL Server DATETIMEOFFSET-Datentyp behoben, bei dem die ODBC-Implementierung die korrekte DDL nicht generieren würde, für Fälle, in denen der Typ über die Methode dialect.type_descriptor() konvertiert wurde, deren Verwendung in einigen dokumentierten Beispielen für TypeDecorator illustriert wird, aber für die meisten Datentypen nicht notwendig ist. Die Regression wurde durch #6366 eingeführt. Im Rahmen dieser Änderung wurde die vollständige Liste der SQL Server-Datumsdatentypen angepasst, um eine „Dialekt-Implementierung“ zurückzugeben, die denselben DDL-Namen wie der Supertyp generiert.

  Referenzen: #7129

1.4.25

Veröffentlicht: 22. September 2021

platform

• [platform] [bug] [regression]

  Regression behoben aufgrund von #7024, bei der die Reorganisation der von der greenlet-Abhängigkeit verwendeten „platform machine“-Namen „aarch64“ falsch schrieb und zusätzlich das Großbuchstaben „AMD64“ wegließ, wie es für Windows-Maschinen benötigt wird. Pull Request von James Dow.

  Referenzen: #7024

1.4.24

Veröffentlicht: 22. September 2021

platform

• [platform] [bug]

  Der Paketselektor „greenlet“ in setup.cfg wurde weiter angepasst, um eine lange Kette von „oder“-Ausdrücken zu verwenden, damit der Vergleich von platform_machine mit einer bestimmten Kennung nur den vollständigen String abgleicht.

  Referenzen: #7024

orm

• [orm] [usecase]

  Ladeoptionen zu Session.merge() und AsyncSession.merge() über einen neuen Parameter Session.merge.options hinzugefügt, der die angegebenen Ladeoptionen auf das intern von merge verwendete get() anwendet und somit das Eager Loading von Beziehungen usw. ermöglicht, wenn der Merge-Prozess ein neues Objekt lädt. Pull Request von Daniel Stone.

  Referenzen: #6955

• [orm] [bug] [regression]

  ORM-Problem behoben, bei dem Spaltenausdrücke, die an query() oder ORM-aktivierte select() übergeben wurden, anhand der Identität des Objekts dedupliziert wurden, z. B. würde ein Satz wie select(A.id, null(), null()) nur einen einzigen „NULL“-Ausdruck erzeugen, was in 1.3 zuvor nicht der Fall war. Die Änderung ermöglicht jedoch auch, dass ORM-Ausdrücke wie angegeben gerendert werden, z. B. wird select(A.data, A.data) eine Ergebniszeile mit zwei Spalten erzeugen.

  Referenzen: #6979

• [orm] [bug] [regression]

  Problem in der kürzlich behobenen Methode Query.with_entities() behoben, bei der das Flag, das die automatische Eindeutigkeit für Legacy-ORM-Query-Objekte bestimmt, nur in Fällen, in denen der Aufruf with_entities() die Query auf die Rückgabe von reinen Spaltenzeilen einstellt, die nicht eindeutig sind, unangemessen auf True gesetzt wurde.

  Referenzen: #6924

engine

• [engine] [usecase] [asyncio]

  Die Schnittstelle, die von angepassten Treibern, wie z. B. den asyncio-Treibern, verwendet wird, um auf das vom Treiber zurückgegebene tatsächliche Verbindungsobjekt zuzugreifen, wurde verbessert.

  Das Objekt _ConnectionFairy hat zwei neue Attribute

  • _ConnectionFairy.dbapi_connection stellt immer ein DBAPI-kompatibles Objekt dar. Für PEP-249-Treiber ist dies die DBAPI-Verbindung, wie sie immer war, zuvor unter dem Attribut .connection zugänglich. Für asyncio-Treiber, die SQLAlchemy in eine PEP-249-Schnittstelle anpasst, ist das zurückgegebene Objekt normalerweise ein SQLAlchemy-Anpassungsobjekt namens AdaptedConnection.

  • _ConnectionFairy.driver_connection stellt immer das tatsächliche Verbindungsobjekt dar, das vom externen PEP-249 DBAPI- oder asynchronen Treiber verwendet wird. Für Standard-PEP-249-DBAPIs ist dies immer dasselbe Objekt wie dbapi_connection. Für einen asyncio-Treiber ist dies das zugrunde liegende reine asyncio-Verbindungsobjekt.

  Das Attribut .connection bleibt verfügbar und ist nun ein Legacy-Alias für .dbapi_connection.

  Siehe auch

  Wie bekomme ich die rohe DBAPI-Verbindung, wenn ich eine Engine verwende?

  Referenzen: #6832

• [engine] [usecase] [orm]

  Neue Methoden Session.scalars(), Connection.scalars(), AsyncSession.scalars() und AsyncSession.stream_scalars() hinzugefügt, die eine Abkürzung für den Anwendungsfall darstellen, ein zeilenorientiertes Result-Objekt zu erhalten und es über die Methode Result.scalars() in ein ScalarResult-Objekt zu konvertieren, um eine Liste von Werten anstelle einer Liste von Zeilen zurückzugeben. Die neuen Methoden sind analog zu den seit langem bestehenden Methoden Session.scalar() und Connection.scalar(), die verwendet wurden, um nur einen einzelnen Wert aus der ersten Zeile zurückzugeben. Pull Request von Miguel Grinberg.

  Referenzen: #6990

• [engine] [bug] [regression]

  Problem behoben, bei dem die Fähigkeit der Methode ConnectionEvents.before_execute(), das übergebene SQL-Anweisungsobjekt zu ändern und das neue Objekt zur Ausführung zurückzugeben, versehentlich entfernt wurde. Dieses Verhalten wurde wiederhergestellt.

  Referenzen: #6913

• [engine] [bug]

  Stellt sicher, dass str() auf ein URL.create.password-Argument aufgerufen wird, was die Verwendung von Objekten ermöglicht, die die Methode __str__() als Passwortattribute implementieren. Es wurde auch klargestellt, dass ein solches Objekt nicht geeignet ist, das Passwort für jede Datenbankverbindung dynamisch zu ändern; stattdessen sollten die Ansätze unter Generieren dynamischer Authentifizierungstoken verwendet werden.

  Referenzen: #6958

• [engine] [bug]

  Problem in URL behoben, bei dem die Validierung von „drivername“ nicht ordnungsgemäß auf den Wert None reagierte, wo ein String erwartet wurde.

  Referenzen: #6983

• [engine] [bug] [postgresql]

  Problem behoben, bei dem eine Engine, bei der create_engine.implicit_returning auf False gesetzt war, nicht funktionierte, wenn die „fast insertmany“-Funktion von PostgreSQL in Verbindung mit einer Sequence verwendet wurde, sowie wenn irgendeine Art von „executemany“ mit „return_defaults()“ in Verbindung mit einer Sequence verwendet wurde. Beachten Sie, dass die PostgreSQL „fast insertmany“-Funktion per Definition „RETURNING“ verwendet, wenn die SQL-Anweisung an den Treiber übergeben wird; insgesamt ist das Flag create_engine.implicit_returning ein Legacy-Flag und hat keine wirkliche Verwendung im modernen SQLAlchemy und wird in einer separaten Änderung als veraltet markiert.

  Referenzen: #6963

sql

• [sql] [usecase]

  Neuer Parameter HasCTE.cte.nesting zum CTE-Konstruktor und zur Methode HasCTE.cte() hinzugefügt, der die CTE als eine kennzeichnet, die innerhalb einer umschließenden CTE verschachtelt bleiben soll, anstatt auf die oberste Ebene der äußersten SELECT verschoben zu werden. Während in den allermeisten Fällen kein Unterschied in der SQL-Funktionalität besteht, haben Benutzer verschiedene Randfälle identifiziert, in denen eine echte Verschachtelung von CTE-Konstrukten wünschenswert ist. Vielen Dank an Eric Masseran für die umfangreiche Arbeit an diesem komplexen Feature.

  Referenzen: #4123

• [sql] [bug]

  Fehlende Methoden in FunctionElement implementiert, die, obwohl ungenutzt, dazu führten, dass pylint sie als nicht implementierte abstrakte Methoden meldete.

  Referenzen: #7052

• [sql] [bug]

  Zwei Probleme behoben, bei denen Kombinationen von select() und join(), wenn sie zur Bildung einer Kopie des Elements angepasst wurden, nicht den vollständigen Zustand aller Spaltenobjekte, die mit Subabfragen assoziiert waren, kopierten. Ein Hauptproblem, das dadurch verursacht wurde, ist, dass die Verwendung der Methode ClauseElement.params() (die wahrscheinlich in eine Legacy-Kategorie verschoben werden sollte, da sie ineffizient und fehleranfällig ist) Kopien der alten BindParameter-Objekte zurückließ, was zu Problemen bei der korrekten Setzung der Parameter zur Ausführungszeit führte.

  Referenzen: #7055

• [sql] [bug]

  Problem im Zusammenhang mit der neuen Funktion HasCTE.add_cte() behoben, bei der die gleichzeitige Kombination von zwei „INSERT..FROM SELECT“-Anweisungen den Überblick über die beiden unabhängigen SELECT-Anweisungen verlor, was zu falschem SQL führte.

  Referenzen: #7036

• [sql] [bug]

  Problem behoben, bei dem die Verwendung von ORM-Spaltenausdrücken als Schlüssel in der Liste von Wörterbüchern, die an Insert.values() für „Multi-Value Insert“ übergeben wurden, nicht korrekt in die entsprechenden Spaltenausdrücke verarbeitet wurde.

  Referenzen: #7060

mypy

• [mypy] [bug]

  Problem behoben, bei dem das mypy-Plugin beim Interpretieren einer query_expression()-Konstruktion abstürzte.

  Referenzen: #6950

• [mypy] [bug]

  Problem im mypy-Plugin behoben, bei dem Spalten eines Mixins nicht korrekt interpretiert wurden, wenn die zugeordnete Klasse auf einer __tablename__-Routine beruhte, die von einer Superklasse stammte.

  Referenzen: #6937

asyncio

• [asyncio] [feature] [mysql]

  Erste Unterstützung für den asyncmy asyncio-Datenbanktreiber für MySQL und MariaDB hinzugefügt. Dieser Treiber ist sehr neu, scheint aber die einzige aktuelle Alternative zum aiomysql-Treiber zu sein, der derzeit als nicht gepflegt gilt und mit aktuellen Python-Versionen nicht funktioniert. Vielen Dank an long2ice für den Pull Request für diesen Dialekt.

  Siehe auch

  asyncmy

  Referenzen: #6993

• [asyncio] [usecase]

  Die AsyncSession unterstützt jetzt die Überschreibung, welche Session als proxy-Instanz verwendet wird. Eine benutzerdefinierte Session-Klasse kann über den Parameter AsyncSession.sync_session_class übergeben oder durch Unterklassenbildung der AsyncSession und Angabe einer benutzerdefinierten AsyncSession.sync_session_class.

  Referenzen: #6746

• [asyncio] [bug]

  Fehler in AsyncSession.execute() und AsyncSession.stream() behoben, die execution_options als Instanz von immutabledict erforderte, wenn sie definiert wurden. Es akzeptiert nun korrekt jede Zuordnung.

  Referenzen: #6943

• [asyncio] [bug]

  Fehlende **kw Argumente zur Methode AsyncSession.connection() hinzugefügt.

• [asyncio] [bug]

  Verwendung von scoped_session mit asyncio-Treibern als veraltet markiert. Bei Verwendung von Asyncio sollte stattdessen async_scoped_session verwendet werden.

  Referenzen: #6746

postgresql

• [postgresql] [bug]

  Qualifizierung des version()-Aufrufs, um Überschattungsprobleme zu vermeiden, falls ein anderer Suchpfad vom Benutzer konfiguriert wird.

  Referenzen: #6912

• [postgresql] [bug]

  Der ENUM-Datentyp ist PostgreSQL-nativ und sollte daher nicht mit dem Flag native_enum=False verwendet werden. Dieses Flag wird nun ignoriert, wenn es an den ENUM-Datentyp übergeben wird, und eine Warnung wird ausgegeben; zuvor führte das Flag dazu, dass das Typobjekt nicht korrekt funktionierte.

  Referenzen: #6106

sqlite

• [sqlite] [bug]

  Fehler behoben, bei dem die Fehlermeldung für ungültige Isolationsstufen von SQLite im pysqlite-Treiber nicht darauf hinwies, dass „AUTOCOMMIT“ eine der gültigen Isolationsstufen ist.

mssql

• [mssql] [bug] [reflection]

  Problem behoben, bei dem sqlalchemy.engine.reflection.has_table() True für lokale temporäre Tabellen zurückgab, die tatsächlich zu einer anderen SQL Server-Sitzung (Verbindung) gehörten. Eine zusätzliche Prüfung wird nun durchgeführt, um sicherzustellen, dass die erkannte temporäre Tabelle tatsächlich der aktuellen Sitzung gehört.

  Referenzen: #6910

oracle

• [oracle] [bug] [performance]

  Ein CAST(VARCHAR2(128)) zu den DDL-Namensparametern „table name“, „owner“ und anderen, die in Reflexionsabfragen gegen Oracle-Systemansichten wie ALL_TABLES, ALL_TAB_CONSTRAINTS usw. verwendet werden, wurde hinzugefügt, um die Indizierung dieser Spalten besser zu ermöglichen, da sie zuvor implizit als NVARCHAR2 behandelt wurden, da Python Unicode für Strings verwendet; diese Spalten sind in allen Oracle-Versionen als VARCHAR2 mit Längen von 30 bis 128 Zeichen dokumentiert, abhängig von der Serverversion. Zusätzlich wurde die Testunterstützung für DDL-Strukturen mit Unicode-Namen gegen Oracle-Datenbanken aktiviert.

  Referenzen: #4486

1.4.23

Veröffentlicht: 18. August 2021

general

• [general] [bug]

  Die Setup-Anforderungen wurden so geändert, dass greenlet nur für Plattformen eine Standardanforderung ist, auf denen greenlet bekanntermaßen installierbar ist und für die es bereits eine vorab kompilierte Binärdatei auf PyPI gibt; die aktuelle Liste ist x86_64 aarch64 ppc64le amd64 win32. Für andere Plattformen wird greenlet nicht standardmäßig installiert, was die Installation und das Ausführen der Testsuite von SQLAlchemy 1.4 auf Plattformen, die greenlet nicht unterstützen, ermöglichen sollte, wobei alle asyncio-Funktionen ausgeschlossen sind. Um mit der greenlet-Abhängigkeit auf einer Maschinenarchitektur außerhalb der obigen Liste zu installieren, kann die Erweiterung [asyncio] durch Ausführen von pip install sqlalchemy[asyncio] einbezogen werden, wodurch dann versucht wird, greenlet zu installieren.

  Zusätzlich wurde die Testsuite repariert, sodass Tests vollständig abgeschlossen werden können, wenn greenlet nicht installiert ist, mit entsprechenden Überspringungen für asyncio-bezogene Tests.

  Referenzen: #6136

orm

• [orm] [usecase]

  Neues Attribut Select.columns_clause_froms hinzugefügt, das die FROM-Liste abruft, die durch die Spaltenklausel der Select-Anweisung impliziert wird. Dies unterscheidet sich von der alten Select.froms-Sammlung dadurch, dass keine ORM-Kompilierungsschritte durchgeführt werden, die notwendigerweise die FROM-Elemente de-annotieren und Dinge wie Joinedloads berechnen usw., was sie zu keinem geeigneten Kandidaten für die Methode Select.select_from() macht. Zusätzlich wird ein neuer Parameter Select.with_only_columns.maintain_column_froms hinzugefügt, der diese Sammlung an Select.select_from() überträgt, bevor die Spaltensammlung ersetzt wird.

  Darüber hinaus wird Select.froms in Select.get_final_froms() umbenannt, um zu betonen, dass diese Sammlung keine einfache Zugriffsfunktion ist, sondern stattdessen basierend auf dem vollständigen Zustand des Objekts berechnet wird, was im ORM-Kontext ein teurer Aufruf sein kann.

  Zusätzlich wird eine Regression behoben, die die Funktion with_only_columns() betraf, um die Anwendung von Kriterien auf Spaltenelemente zu unterstützen, die entweder durch Select.with_only_columns() oder Query.with_entities() ersetzt wurden, was als Teil von #6503 in 1.4.19 fehlerhaft war.

  Referenzen: #6808

• [orm] [bug] [sql]

  Problem behoben, bei dem ein gebundener Parameter, der "geklont" wurde, einen Namenskonflikt im Compiler verursachte, wenn mehr als ein Klon dieses Parameters gleichzeitig in einer einzelnen Anweisung verwendet wurde. Dies konnte insbesondere bei ORM-Abfragen mit Single Table Inheritance auftreten, die denselben "Diskriminator"-Wert mehrmals in einer Abfrage angaben.

  Referenzen: #6824

• [orm] [bug]

  Problem in Ladesstrategien behoben, bei dem die Verwendung der Methode Load.options(), insbesondere bei der Verschachtelung mehrerer Aufrufe, einen übermäßig langen und vor allem nicht-deterministischen Cache-Schlüssel generierte, was zu sehr großen Cache-Schlüsseln führte und eine effiziente Cache-Nutzung verhinderte, sowohl in Bezug auf den gesamten verwendeten Speicher als auch auf die Anzahl der im Cache verwendeten Einträge.

  Referenzen: #6869

• [orm] [bug]

  Überarbeitete die Art und Weise, wie der Zugriff auf ORMExecuteState.user_defined_options UserDefinedOption und verwandte Options-Objekte aus dem Kontext erhält, mit besonderem Schwerpunkt auf "selectinload" bei der Ladesstrategie, wo dies zuvor nicht funktionierte; andere Strategien hatten dieses Problem nicht. Die Objekte, die mit der aktuell ausgeführten Abfrage verknüpft sind und nicht mit einer zwischengespeicherten Abfrage, werden nun bedingungslos weitergegeben. Dies trennt sie im Wesentlichen von den "Ladesstrategie"-Optionen, die explizit mit dem kompilierten Zustand einer Abfrage verknüpft sind und in Bezug auf die zwischengespeicherte Abfrage verwendet werden müssen.

  Die Auswirkung dieser Korrektur ist, dass eine benutzerspezifische Option, wie sie im dogpile.caching-Beispiel verwendet wird, sowie für andere Rezepte wie die Definition einer "Shard ID" für die horizontale Sharding-Erweiterung, korrekt an eager- und lazy-Loader weitergegeben wird, unabhängig davon, ob letztendlich eine zwischengespeicherte Abfrage aufgerufen wurde.

  Referenzen: #6887

• [orm] [bug]

  Problem behoben, bei dem die Unit of Work intern eine als 2.0 veraltete SQL-Ausdrucksform verwendete und eine Deprecation-Warnung ausgab, wenn SQLALCHEMY_WARN_20 aktiviert war.

  Referenzen: #6812

• [orm] [bug]

  Problem in selectinload() behoben, wo die Verwendung des neuen Features PropComparator.and_() innerhalb von Optionen, die mehr als eine Ebene tief verschachtelt waren, die Aktualisierung gebundener Parameterwerte in den verschachtelten Kriterien als Nebeneffekt des SQL-Abfrage-Cachings fehlschlagen ließ.

  Referenzen: #6881

• [orm] [bug]

  ORM-Lader-Interna überarbeitet, um das 1.4 eingeführte "Lambda-Caching"-System nicht mehr zu verwenden, und eine Stelle repariert, die noch das vorherige "Baked Query"-System für eine Abfrage verwendete. Das Lambda-Caching-System bleibt eine effektive Methode, um den Overhead beim Aufbau von Abfragen mit relativ festen Nutzungsmustern zu reduzieren. Im Falle von Ladesstrategien sind die verwendeten Abfragen dafür verantwortlich, durch viele beliebige Optionen und Kriterien zu navigieren, die sowohl generiert als auch manchmal vom Endbenutzercode konsumiert werden, was das Lambda-Cache-Konzept nicht effizienter macht als die Nichtverwendung, auf Kosten höherer Komplexität. Insbesondere werden die Probleme, die von #6881 und #6887 genannt werden, durch die Entfernung dieses Features intern erheblich vereinfacht.

  Referenzen: #6079, #6889

• [orm] [bug]

  Problem behoben, bei dem das Bundle-Konstrukt keine korrekten Cache-Schlüssel erzeugte, was zu einer ineffizienten Nutzung des Abfrage-Caches führte. Dies hatte einige Auswirkungen auf die "selectinload"-Strategie und wurde als Teil von #6889 identifiziert.

  Referenzen: #6889

sql

• [sql] [bug]

  Problem in CTE behoben, bei der die neue Methode HasCTE.add_cte(), die in Version 1.4.21 / #6752 hinzugefügt wurde, für "Compound Select"-Strukturen wie union(), union_all(), except() usw. nicht korrekt funktionierte. Pull Request von Eric Masseran.

  Referenzen: #6752

• [sql] [bug]

  Problem in der Methode CacheKey.to_offline_string(), die vom dogpile.caching-Beispiel verwendet wird, behoben, bei der der Versuch, einen korrekten Cache-Schlüssel aus der vom Lazy Loader generierten speziellen "Lambda"-Abfrage zu erstellen, die Parameterwerte nicht einschloss, was zu einem fehlerhaften Cache-Schlüssel führte.

  Referenzen: #6858

• [sql] [bug]

  Die Warnfunktion "from linter" wurde angepasst, um eine Join-Kette zu unterstützen, die tiefer als eine Ebene ist, bei der die ON-Klauseln die Ziele nicht explizit abgleichen, wie z. B. ein Ausdruck wie "ON TRUE". Dieser Verwendungszweck soll die Warnung vor kartesischen Produkten einfach dadurch aufheben, dass es einen JOIN von "a nach b" gibt, was im Fall einer Join-Kette mit mehr als einem Element nicht funktionierte.

  Referenzen: #6886

• [sql] [bug]

  Problem im Lambda-Caching-System behoben, bei dem ein Element einer Abfrage, das keinen Cache-Schlüssel erzeugt, wie eine benutzerdefinierte Option oder ein Klausel-Element, dennoch unangemessen den Ausdruck im "Lambda-Cache" populierte.

schema

• [schema] [enum]

  Vereinheitlichung des Verhaltens von Enum in nativen und nicht-nativen Implementierungen bezüglich der akzeptierten Werte für ein Enum mit Aliassen. Wenn Enum.omit_aliases False ist, werden alle Werte, einschließlich Aliassen, als gültige Werte akzeptiert. Wenn Enum.omit_aliases True ist, werden nur nicht-aliassierte Werte als gültige Werte akzeptiert.

  Referenzen: #6146

mypy

• [mypy] [usecase]

  Unterstützung für SQLAlchemy-Klassen hinzugefügt, die im Benutzercode mit "generischer Klassen"-Syntax wie von sqlalchemy2-stubs definiert, z. B. Column[String], ohne dass diese Konstrukte in einem TYPE_CHECKING-Block qualifiziert werden müssen, indem die Python-Spezialmethode __class_getitem__() implementiert wurde, die es dieser Syntax ermöglicht, zur Laufzeit fehlerfrei zu passieren.

  Referenzen: #6759, #6804

postgresql

• [postgresql] [bug]

  Das Flag "is_comparison" wurde zu den PostgreSQL-Operatoren "overlaps", "contained_by" und "contains" hinzugefügt, damit sie in relevanten ORM-Kontexten sowie in Verbindung mit dem "from linter"-Feature funktionieren.

  Referenzen: #6886

mssql

• [mssql] [bug] [sql]

  Problem behoben, bei dem das Compiler-Flag literal_binds, das extern zur Inline-Darstellung gebundener Parameter verwendet wird, nicht funktionierte, wenn es mit einer bestimmten Klasse von Parametern, bekannt als "literal_execute", verwendet wurde. Dies umfasst Dinge wie LIMIT- und OFFSET-Werte für Dialekte, bei denen die Treiber keinen gebundenen Parameter zulassen, wie z. B. die "TOP"-Klausel von SQL Server. Das Problem betraf lokal anscheinend nur den MSSQL-Dialekt.

  Referenzen: #6863

misc

• [bug] [ext]

  Problem behoben, bei dem die horizontale Sharding-Erweiterung eine einfache Text-SQL-Anweisung, die an Session.execute() übergeben wurde, nicht korrekt berücksichtigte.

  Referenzen: #6816

1.4.22

Veröffentlicht: 21. Juli 2021

orm

• [orm] [bug]

  Problem in der neuen Methode Table.table_valued() behoben, bei der die resultierende TableValuedColumn-Konstruktion nicht korrekt auf Alias-Anpassungen reagierte, wie sie im ORM verwendet werden, z. B. für Eager Loading, Polimorphic Loading usw.

  Referenzen: #6775

• [orm] [bug]

  Problem behoben, bei dem die Verwendung der Methode Result.unique() mit einem ORM-Ergebnis, das Spaltenausdrücke mit nicht hashbaren Typen enthielt, wie z. B. JSON oder ARRAY ohne Tupel, stillschweigend auf die Verwendung der Funktion id() zurückfiel, anstatt einen Fehler auszulösen. Dies löst nun einen Fehler aus, wenn die Methode Result.unique() in einer ORM-Abfrage im 2.0-Stil verwendet wird. Zusätzlich wird die Hashbarkeit für Ergebniswerte unbekannten Typs als True angenommen, was oft passiert, wenn SQL-Funktionen mit unbekanntem Rückgabetyp verwendet werden; wenn Werte wirklich nicht hashbar sind, wird hash() selbst einen Fehler auslösen.

  Für Legacy-ORM-Abfragen, da das Legacy-Objekt Query in allen Fällen eindeutig ist, bleiben die alten Regeln in Kraft, nämlich die Verwendung von id() für Ergebniswerte unbekannten Typs, da diese Legacy-Eindeutigkeit hauptsächlich dem Zweck dient, ORM-Entitäten und nicht Spaltenwerte eindeutig zu machen.

  Referenzen: #6769

• [orm] [bug]

  Problem behoben, bei dem das Löschen von Mappern während z. B. dem Abbau der Testsuite eine Warnung "dictionary changed size" während der Garbage Collection verursachen konnte, aufgrund der Iteration eines Weak-Referencing-Dictionarys. Eine list() wurde angewendet, um zu verhindern, dass die gleichzeitige GC diese Operation beeinträchtigt.

  Referenzen: #6771

• [orm] [bug] [regression]

  Kritisches Caching-Problem behoben, bei dem die Persistenzfunktion des ORM, die INSERT..RETURNING verwendet, eine falsche Abfrage zwischenspeicherte, wenn "Bulk Save" und Standard-"Flush"-Formen von INSERT gemischt wurden.

  Referenzen: #6793

engine

• [engine] [bug]

  Einige Schutzmaßnahmen gegen KeyError im Ereignissystem hinzugefügt, um den Fall abzudecken, dass der Interpreter heruntergefahren wird, gleichzeitig Engine.dispose() aufgerufen wird, was zu Stapelverfolgungswarnungen führen würde.

  Referenzen: #6740

sql

• [sql] [bug]

  Problem behoben, bei dem die Verwendung des Parameters case.whens, der ein Wörterbuch positionell und nicht als Schlüsselwortargument übergibt, eine 2.0-Deprecationswarnung ausgab, die sich auf die Deprecation des positionellen Übergebens einer Liste bezog. Das Wörterbuchformat von "whens", positionell übergeben, wird weiterhin unterstützt und wurde versehentlich als veraltet markiert.

  Referenzen: #6786

• [sql] [bug]

  Problem behoben, bei dem typenspezifische gebundene Parameter-Handler nicht aufgerufen wurden, wenn die Methode Insert.values() mit dem Python-Wert None verwendet wurde; dies wurde insbesondere bei der Verwendung des JSON-Datentyps sowie verwandter PostgreSQL-spezifischer Typen wie JSONB bemerkt, die den Python-Wert None nicht korrekt in JSON null kodieren würden. Das Problem wurde jedoch auf jeden gebundenen Parameter-Handler in Verbindung mit dieser spezifischen Methode von Insert verallgemeinert.

  Referenzen: #6770

1.4.21

Veröffentlicht: 14. Juli 2021

orm

• [orm] [usecase]

  Der Ansatz zur Nachverfolgung des Verlaufs von skalaren Objektbeziehungen, die keine Many-to-One sind (d. h. One-to-One-Beziehungen, die andernfalls One-to-Many wären), wurde geändert. Beim Ersetzen eines One-to-One-Werts wird der "alte" Wert, der ersetzt wird, nicht mehr sofort geladen, sondern während des Flush-Prozesses behandelt. Dies eliminiert ein historisch problematische Lazy Load, das sonst oft beim Zuweisen zu einem One-to-One-Attribut auftritt und insbesondere bei Verwendung von "lazy='raise'" sowie bei Asyncio-Anwendungsfällen problematisch ist.

  Diese Änderung führt zu einer Verhaltensänderung innerhalb des Ereignisses AttributeEvents.set(), das jedoch derzeit dokumentiert ist: Das Ereignis, das auf ein solches One-to-One-Attribut angewendet wird, empfängt den "alten" Parameter nicht mehr, wenn er entladen ist und das Flag relationship.active_history nicht gesetzt ist. Wie in AttributeEvents.set() dokumentiert, muss das active_history-Flag entweder mit dem Ereignis-Listener oder mit der Beziehung gesetzt werden, wenn der Ereignis-Handler den "alten" Wert erhalten muss, wenn das Ereignis ausgelöst wird. Dies ist bereits das Verhalten bei anderen Attributarten wie Many-to-One und Spaltenwertreferenzen.

  Die Änderung verzögert zusätzlich die Aktualisierung einer Rückreferenz auf den "alten" Wert in dem selteneren Fall, dass der "alte" Wert lokal in der Sitzung vorhanden, aber für die betreffende Beziehung nicht geladen ist, bis zum nächsten Flush. Wenn dies ein Problem verursacht, kann erneut das normale Flag relationship.active_history auf True für die Beziehung gesetzt werden.

  Referenzen: #6708

• [orm] [bug] [regression]

  Regression behoben, die in Version 1.4.19 aufgrund von #6503 und verwandten Problemen mit Query.with_entities() aufgetreten war, bei der die neue verwendete Struktur unangemessen an eine umschließende Query übertragen wurde, wenn Mengenoperationen wie Query.union() verwendet wurden, wodurch die darin enthaltenen JOIN-Anweisungen auch auf die äußere Abfrage angewendet wurden.

  Referenzen: #6698

• [orm] [bug] [regression]

  Regression behoben, die in Version 1.4.3 aufgrund von #6060 aufgetreten war, bei der Regeln, die die ORM-Anpassung abgeleiteter wählbarer Elemente einschränken, mit anderen ORM-Anpassungsfällen kollidierten, in diesem Fall bei der Anwendung von Anpassungen für with_polymorphic() gegen eine Zuordnung, die eine column_property() verwendet, die wiederum einen skalarren Select verwendet, der ein aliased()-Objekt der zugeordneten Tabelle enthält.

  Referenzen: #6762

• [orm] [regression]

  ORM-Regression behoben, bei der Ad-hoc-Labelnamen, die für Hybrid-Properties und möglicherweise andere ähnliche Arten von ORM-aktivierten Ausdrücken generiert wurden, normalerweise durch Unterabfragen nach außen propagiert wurden, wodurch der Name selbst bei der Auswahl aus Unterabfragen in den endgültigen Schlüsseln des Ergebnissatzes beibehalten wurde. In diesem Fall werden nun zusätzliche Zustände verfolgt, die nicht verloren gehen, wenn ein Hybrid aus einem Core-Select / Unterabfrage ausgewählt wird.

  Referenzen: #6718

sql

• [sql] [usecase]

  Hinzugefügte neue Methode HasCTE.add_cte() zu jeder der select(), insert(), update() und delete() Konstrukten. Diese Methode fügt die gegebene CTE als eine „unabhängige“ CTE der Anweisung hinzu, was bedeutet, dass sie im WITH-Clause oberhalb der Anweisung bedingungslos gerendert wird, auch wenn sie sonst nicht in der primären Anweisung referenziert wird. Dies ist ein häufiger Anwendungsfall in der PostgreSQL-Datenbank, wo eine CTE für eine DML-Anweisung verwendet wird, die unabhängig von der primären Anweisung auf Datenbankzeilen ausgeführt wird.

  Referenzen: #6752

• [sql] [bug]

  Problem in CTE-Konstrukten behoben, bei dem eine rekursive CTE, die sich auf eine SELECT bezog, die doppelte Spaltennamen hatte, die in 1.4 typischerweise durch Label-Logik dedupliziert wurden, nicht korrekt auf den deduplizierten Label-Namen innerhalb der WITH-Klausel verwies.

  Referenzen: #6710

• [sql] [bug] [regression]

  Regression behoben, bei der der tablesample()-Konstrukt nicht ausführbar war, wenn es mit einem Gleitkomma-Samplingwert konstruiert wurde, der nicht innerhalb einer SQL-Funktion eingebettet war.

  Referenzen: #6735

postgresql

• [postgresql] [bug]

  Problem in Insert.on_conflict_do_nothing() und Insert.on_conflict_do_update() behoben, bei der der Name einer eindeutigen Einschränkung, die als constraint-Parameter übergeben wurde, für die Länge nicht richtig gekürzt wurde, wenn sie auf einer Benennungskonvention basierte, die einen zu langen Namen für die PostgreSQL-Maximalbezeichnerlänge von 63 Zeichen erzeugte, auf die gleiche Weise wie in einer CREATE TABLE-Anweisung.

  Referenzen: #6755

• [postgresql] [bug]

  Problem behoben, bei dem der PostgreSQL ENUM-Datentyp, eingebettet im ARRAY-Datentyp, beim Erstellen/Löschen nicht korrekt ausgegeben wurde, wenn das schema_translate_map-Feature ebenfalls verwendet wurde. Zusätzlich wird ein verwandtes Problem behoben, bei dem dasselbe schema_translate_map-Feature nicht für den ENUM-Datentyp in Kombination mit einem CAST funktionierte, was auch intrinsisch für die Funktionsweise der ARRAY(ENUM)-Kombination im PostgreSQL-Dialekt ist.

  Referenzen: #6739

• [postgresql] [bug]

  Problem in Insert.on_conflict_do_nothing() und Insert.on_conflict_do_update() behoben, bei der der Name einer eindeutigen Einschränkung, die als constraint-Parameter übergeben wurde, nicht richtig zitiert wurde, wenn sie Zeichen enthielt, die eine Zitierung erforderten.

  Referenzen: #6696

mssql

• [mssql] [bug] [regression]

  Regression behoben, bei der die spezielle Behandlung von Punkt-Schema-Namen für den SQL Server-Dialekt nicht korrekt funktionierte, wenn der Punkt-Schema-Name innerhalb des schema_translate_map-Features verwendet wurde.

  Referenzen: #6697

1.4.20

Veröffentlicht: 28. Juni 2021

orm

• [orm] [bug] [regression]

  Regression im ORM bezüglich eines internen Rekonstitutionsschritts für den with_polymorphic()-Konstrukt behoben, wenn das vom Benutzer verwendete Objekt während der Abfrageverarbeitung vom Garbage Collector bereinigt wurde. Die Rekonstitution stellte sicher, dass die Unterentitäten für den „polymorphen“ Fall behandelt wurden, was zu einem AttributeError führte.

  Referenzen: #6680

• [orm] [bug] [regression]

  Angepasste Query.union() und ähnliche Mengenoperationen, um korrekt mit den neuen Funktionen kompatibel zu sein, die gerade in #6661 mit SQLAlchemy 1.4.19 hinzugefügt wurden, sodass die als Elemente der UNION oder anderer Mengenoperationen gerenderten SELECT-Anweisungen direkt zugeordnete Spalten enthalten, die als verzögert zugeordnet sind; dies behebt sowohl eine Regression, die UNIONs mit mehreren Verschachtelungsebenen betraf und zu einem Spaltenkonflikt führte, als auch ermöglicht es, dass die undefer()-Option auf der obersten Ebene einer solchen Query verwendet werden kann, ohne die Option auf jedes der Elemente innerhalb der UNION anwenden zu müssen.

  Referenzen: #6678

• [orm] [bug]

  Angepasste die Prüfung im Mapper für ein aufrufbaren Objekt, das als @validates-Validierungsfunktion oder @reconstructor-Rekonstruktionsfunktion verwendet wird, um „aufrufbar“ liberaler zu prüfen, um Objekte zu unterstützen, die auf grundlegenden Attributen wie __func__ und __call__ basieren, anstatt auf MethodType / FunctionType zu testen, damit Dinge wie Cython-Funktionen ordnungsgemäß funktionieren. Pull-Request freundlicherweise von Miłosz Stypiński.

  Referenzen: #6538

engine

• [engine] [bug]

  Problem in der C-Erweiterung für die Row-Klasse behoben, die zu einem Speicherleck führen konnte, in dem unwahrscheinlichen Fall eines Row-Objekts, das auf ein ORM-Objekt verwies, das dann mutiert wurde, um auf die Row selbst zu verweisen, wodurch ein Zyklus entstand. Die Python C-APIs zur Verfolgung von GC-Zyklen wurden der nativen Row-Implementierung hinzugefügt, um diesen Fall zu berücksichtigen.

  Referenzen: #5348

• [engine] [bug]

  Behobenes altes Problem, bei dem eine select(), die gegen das Token „*“ ausgeführt wurde und dann genau eine Spalte ergab, den Spaltennamen von cursor.description nicht korrekt in die Schlüssel des Ergebnisobjekts organisieren konnte.

  Referenzen: #6665

sql

• [sql] [usecase]

  Füge einen `impl`-Parameter zum Konstruktor von PickleType hinzu, der es erlaubt, jeden beliebigen Typ anstelle der Standardimplementierung von LargeBinary zu verwenden. Pull-Request freundlicherweise von jason3gb.

  Referenzen: #6646

• [sql] [bug] [orm]

  Die Klassenhierarchie für Sequence und die allgemeinere Basisklasse DefaultGenerator korrigiert, da diese als „ausführbare“ Anweisungen Executable in ihre Hierarchie aufnehmen müssen, nicht nur StatementRole, wie es zuvor willkürlich auf Sequence angewendet wurde. Die Korrektur ermöglicht es Sequence, in allen .execute()-Methoden zu funktionieren, einschließlich mit Session.execute(), was in dem Fall, dass auch ein SessionEvents.do_orm_execute()-Handler eingerichtet war, nicht funktionierte.

  Referenzen: #6668

schema

• [schema] [bug]

  Problem behoben, bei dem die Übergabe von None für den Wert von Table.prefixes keine leere Liste speicherte, sondern die Konstante None, was von Drittanbieter-Dialekten unerwartet sein könnte. Das Problem wird durch eine Verwendung in neueren Versionen von Alembic aufgedeckt, die None für diesen Wert übergeben. Pull-Request freundlicherweise von Kai Mueller.

  Referenzen: #6685

mysql

• [mysql] [usecase]

  Kleine Anpassung im Tabellenreflexionsfeature des MySQL-Dialekts, um alternative MySQL-orientierte Datenbanken wie TiDB zu berücksichtigen, die ihre eigenen „comment“-Direktiven am Ende einer Constraint-Direktive innerhalb von „CREATE TABLE“ enthalten, bei denen das Format keinen zusätzlichen Leerzeichen nach dem Kommentar hat, in diesem Fall das TiDB „clustered index“-Feature. Pull-Request freundlicherweise von Daniël van Eeden.

  Referenzen: #6659

misc

• [bug] [ext] [regression]

  Regression in der Erweiterung sqlalchemy.ext.automap behoben, so dass der Anwendungsfall der Erstellung einer explizit zugeordneten Klasse zu einer Tabelle, die auch das relationship.secondary-Element einer relationship() ist, die automap generieren wird, die in 1.4 eingeführten „overlaps“-Warnungen ausgibt und unter relationship X will copy column Q to column P, which conflicts with relationship(s): ‘Y’ diskutiert wird. Während die Generierung dieses Falls aus automap immer noch den gleichen Einschränkungen unterliegt, die in der „overlaps“-Warnung erwähnt werden, da automap hauptsächlich für eher Ad-hoc-Anwendungsfälle gedacht ist, wird die Bedingung, die die Warnung auslöst, deaktiviert, wenn eine Many-to-Many-Beziehung mit diesem spezifischen Muster generiert wird.

  Referenzen: #6679

1.4.19

Veröffentlicht: 22. Juni 2021

orm

• [orm] [bug] [regression]

  Weitere Regressionen im gleichen Bereich wie #6052 behoben, bei denen Loader-Optionen sowie Aufrufe von Methoden wie Query.join() fehlschlugen, wenn die linke Seite der Anweisung, von der die Option/Join abhängt, durch Verwendung der Methode Query.with_entities() ersetzt wurde oder wenn 2.0-Stil-Abfragen unter Verwendung der Methode Select.with_only_columns() verwendet wurden. Ein neuer Satz von Zuständen wurde den Objekten hinzugefügt, der die „linken“ Entitäten verfolgt, gegen die die Optionen / der Join gemacht wurden, was memoisiert wird, wenn die führenden Entitäten geändert werden.

  Referenzen: #6253, #6503

• [orm] [bug]

  Verfeinert das Verhalten des ORM-Subquery-Renderings in Bezug auf verzögerte Spalten und Spalteneigenschaften, um besser mit 1.3 kompatibel zu sein und gleichzeitig die neueren Features von 1.4 zu ermöglichen. Da eine Subquery in 1.4 keine Loader-Optionen, einschließlich undefer(), verwendet, rendert eine Subquery, die sich auf ORM-Entitäten mit verzögerten Attributen bezieht, nun diese verzögerten Attribute, die sich direkt auf zugeordnete Tabellenspalten beziehen, da diese in der äußeren SELECT benötigt werden, falls die äußere SELECT diese Spalten verwendet; eine verzögerte Attribut, das sich auf einen zusammengesetzten SQL-Ausdruck bezieht, wie wir es normalerweise bei column_property() tun, wird jedoch nicht Teil der Subquery sein, da diese explizit ausgewählt werden können, wenn sie in der Subquery benötigt werden. Wenn die Entität aus dieser Subquery SELECTiert wird, kann der Spaltenausdruck immer noch „außen“ in Bezug auf die abgeleiteten Subquery-Spalten gerendert werden. Dies erzeugt im Wesentlichen das gleiche Verhalten wie bei der Arbeit mit 1.3. In diesem Fall muss die Korrektur jedoch auch sicherstellen, dass die .selected_columns-Sammlung einer ORM-aktivierten select() diesen Regeln folgt, was insbesondere rekursive CTEs in diesem Szenario korrekt rendert, die zuvor aufgrund dieses Problems nicht korrekt gerendert wurden.

  Referenzen: #6661

sql

• [sql] [bug]

  Problem in CTE-Konstrukten, hauptsächlich relevant für ORM-Anwendungsfälle, behoben, bei denen eine rekursive CTE, die sich auf „anonyme“ Labels bezieht, wie sie in ORM column_property()-Mappings vorkommen, im Abschnitt WITH RECURSIVE xyz(...) als ihr rohes internes Label und nicht als sauber anonymisierter Name gerendert wurde.

  Referenzen: #6663

mypy

• [mypy] [bug]

  Problem im mypy-Plugin behoben, bei dem die Klasseninformationen für eine benutzerdefinierte deklarative Basis nicht korrekt bei einem zwischengespeicherten mypy-Durchlauf behandelt wurden, was zu einem AssertionError führte.

  Referenzen: #6476

asyncio

• [asyncio] [usecase]

  Implementiert async_scoped_session, um einige asyncio-bezogene Inkompatibilitäten zwischen scoped_session und AsyncSession zu beheben, bei denen einige Methoden (insbesondere die Methode async_scoped_session.remove()) mit dem Schlüsselwort await verwendet werden sollten.

  Siehe auch

  Verwendung von asyncio scoped session

  Referenzen: #6583

• [asyncio] [bug] [postgresql]

  Fehler in der asyncio-Implementierung behoben, bei der das Greenlet-Adaptionssystem Unterklassen von BaseException, insbesondere aber nicht ausschließlich asyncio.CancelledError, nicht an die Ausnahmebehandlungslogik des Engines zur Invalidierung und Bereinigung der Verbindung weiterleitete, wodurch verhindert wurde, dass Verbindungen korrekt entsorgt wurden, wenn eine Aufgabe abgebrochen wurde.

  Referenzen: #6652

postgresql

• [postgresql] [bug] [oracle]

  Problem behoben, bei dem der INTERVAL-Datentyp unter PostgreSQL und Oracle ein AttributeError erzeugte, wenn er im Kontext einer Vergleichsoperation gegen ein timedelta()-Objekt verwendet wurde. Pull-Request freundlicherweise von MajorDallas.

  Referenzen: #6649

• [postgresql] [bug]

  Problem behoben, bei dem das Pool-Feature „pre ping“ implizit eine Transaktion startete, die dann benutzerdefinierte Transaktionsflags wie PostgreSQLs „read only“-Modus störte, wenn sie mit dem psycopg2-Treiber verwendet wurden.

  Referenzen: #6621

mysql

• [mysql] [usecase]

  Neuer Konstrukt match hinzugefügt, der die volle Bandbreite des MySQL MATCH-Operators einschließlich Multi-Column-Unterstützung und Modifikatoren bereitstellt. Pull-Request freundlicherweise von Anton Kovalevich.

  Siehe auch

  match

  Referenzen: #6132

mssql

• [mssql] [change]

  Verbesserungen am Server-Versions-Regexp des pymssql-Dialekts vorgenommen, um einen Regexp-Überlauf bei ungültigen Versionsstrings zu verhindern.

  Referenzen: #6253, #6503

• [mssql] [bug]

  Fehler behoben, bei dem das Feature „schema_translate_map“ in Verbindung mit einem INSERT in eine Tabelle mit einer IDENTITY-Spalte nicht korrekt funktionierte, wobei der Wert der IDENTITY-Spalte in den Werten des INSERT angegeben wurde, was das Feature von SQLAlchemy auslöste, IDENTITY INSERT auf „on“ zu setzen; in dieser Direktive konnte die Schema-Übersetzungskarte nicht eingehalten werden.

  Referenzen: #6658

1.4.18

Veröffentlicht: 10. Juni 2021

orm

• [orm] [bug]

  Klarstellung des aktuellen Zwecks des Flags relationship.bake_queries, das in 1.4 die Aktivierung oder Deaktivierung des „Lambda-Cachings“ von Anweisungen innerhalb der Lade-Strategien „lazyload“ und „selectinload“ dient; dies ist getrennt vom grundlegenderen SQL-Abfrage-Cache, der für die meisten Anweisungen verwendet wird. Zusätzlich verwendet der Lazy Loader keinen eigenen Cache mehr für Many-to-One-SQL-Abfragen, was eine Implementierungssonderheit war, die bei keinem anderen Ladeszenario existiert. Schließlich wurde die „lru cache“-Warnung, die die Lazyloader- und Selectinloader-Strategien bei der Verarbeitung einer breiten Palette von Klassen/Beziehungs-Kombinationen ausgeben konnten, entfernt; basierend auf der Analyse einiger Endbenutzerfälle, deutet diese Warnung auf kein signifikantes Problem hin. Während das Setzen von bake_queries=False für eine solche Beziehung diesen Cache nicht mehr verwendet, gibt es in diesem Fall keinen besonderen Leistungsvorteil, da die Verwendung von keinem Caching gegenüber der Verwendung eines Caches, der oft aktualisiert werden muss, wahrscheinlich immer noch die Verwendung des Caches überwiegt.

  Referenzen: #6072, #6487

• [orm] [bug] [regression]

  Die Art und Weise, wie Klassen wie scoped_session und AsyncSession von der Basisklasse Session generiert werden, wurde angepasst, sodass benutzerdefinierte Session-Unterklassen wie die von Flask-SQLAlchemy verwendete keine Positionsargumente mehr implementieren müssen, wenn sie die Superklassenmethode aufrufen, und weiterhin die gleichen Argumentstile wie in früheren Versionen verwenden können.

  Referenzen: #6285

• [orm] [bug] [regression]

  Problem behoben, bei dem die Abfrageerstellung für joinedload bei einer komplexen linken Seite, die verknüpfte Tabellenvererbung beinhaltete, aufgrund eines Klauseladaptionsproblems keine korrekte Abfrage erzeugen konnte.

  Referenzen: #6595

• [orm] [bug] [performance] [regression]

  Regression behoben, bei der das ORM eine zugeordnete Spalte einer Ergebniszeile zuordnete. In Fällen wie dem joined eager loading konnte eine etwas teurere „Fallback“-Lösung zur Einrichtung dieser Zuordnung erfolgen, aufgrund von Logik, die seit 1.3 entfernt wurde. Das Problem konnte auch zu Deprecationswarnungen bezüglich der Spaltenzuordnung führen, wenn eine 1.4-Stil-Abfrage mit joined eager loading verwendet wurde.

  Referenzen: #6596

• [orm] [bug]

  Problem im experimentellen Anwendungsfall „select ORM objects from INSERT/UPDATE“ behoben, bei dem ein Fehler auftrat, wenn die Anweisung sich auf eine Single-Table-Inheritance-Unterklasse bezog.

  Referenzen: #6591

• [orm] [bug]

  Die Warnung, die für relationship() ausgegeben wird, wenn mehrere Beziehungen sich gegenseitig in Bezug auf die geschriebenen Fremdschlüsselattribute überlappen, enthält nun das spezifische „overlaps“-Argument, das verwendet werden kann, um die Warnung zu unterdrücken, ohne das Mapping zu ändern.

  Referenzen: #6400

asyncio

• [asyncio] [usecase]

  Implementiert eine neue Registry-Architektur, die es ermöglicht, die Async-Version eines Objekts, wie AsyncSession, AsyncConnection usw., anhand des proxy-gepufferten „sync“-Objekts, d.h. Session, Connection, zu lokalisieren. Zuvor, soweit solche Lookup-Funktionen verwendet wurden, wurde jedes Mal ein Async-Objekt neu erstellt, was nicht ideal war, da die Identität und der Zustand des „async“-Objekts über Aufrufe hinweg nicht erhalten blieben.

  Von dort wurden neue Hilfsfunktionen async_object_session(), async_session() sowie ein neues InstanceState-Attribut InstanceState.async_session hinzugefügt, die dazu dienen, die ursprüngliche AsyncSession, die mit einem ORM-gemappten Objekt assoziiert ist, eine mit einer AsyncSession assoziierte Session und eine mit einem InstanceState assoziierte AsyncSession zu ermitteln.

  Dieser Patch implementiert außerdem die neuen Methoden AsyncSession.in_nested_transaction(), AsyncSession.get_transaction(), AsyncSession.get_nested_transaction().

  Referenzen: #6319

• [asyncio] [bug]

  Behobenes Problem, das bei der Verwendung von NullPool oder StaticPool mit einer asynchronen Engine auftrat. Dies betraf hauptsächlich das aiosqlite-Dialekt.

  Referenzen: #6575

• [asyncio] [bug]

  Hinzugefügt: asyncio.exceptions.TimeoutError, asyncio.exceptions.CancelledError als sogenannte „Exit Exceptions“, eine Klasse von Ausnahmen, die Dinge wie GreenletExit und KeyboardInterrupt umfasst und als Ereignisse betrachtet werden, die eine DBAPI-Verbindung in einem unbrauchbaren Zustand ansehen lassen, in dem sie wiederverwendet werden sollte.

  Referenzen: #6592

postgresql

• [postgresql] [bug] [regression]

  Behobene Regression, bei der die PostgreSQL-Struktur „INSERT..ON CONFLICT“ mit dem psycopg2-Treiber fehlschlug, wenn sie in einem „executemany“-Kontext zusammen mit gebundenen Parametern in der „SET“-Klausel verwendet wurde. Dies lag an der impliziten Verwendung der schnellen Ausführungshelfer von psycopg2, die für diese Art von INSERT-Anweisung nicht geeignet sind; da diese Helfer in 1.4 Standard sind, handelt es sich hierbei effektiv um eine Regression. Zusätzliche Prüfungen, um diese Art von Anweisung von dieser speziellen Erweiterung auszuschließen, wurden hinzugefügt.

  Referenzen: #6581

sqlite

• [sqlite] [bug]

  Hinweis zur Verschlüsselung hinzugefügt, bezüglich der Verschlüsselungs-Pragmas für pysqlcipher, die in der URL übergeben werden.

  Diese Änderung wird auch **zurückportiert** auf: 1.3.25

  Referenzen: #6589

• [sqlite] [bug] [regression]

  Die Korrektur für pysqlcipher, die in Version 1.4.3 veröffentlicht wurde #5848, funktionierte leider nicht. Der neue on_connect_url Hook erhielt unter normaler Verwendung von create_engine() fälschlicherweise kein URL-Objekt, sondern eine unbehandelte Zeichenkette. Die Testsuite konnte die tatsächlichen Bedingungen, unter denen dieser Hook aufgerufen wird, nicht vollständig einrichten. Dies wurde behoben.

  Referenzen: #6586

1.4.17

Veröffentlicht: 29. Mai 2021

orm

• [orm] [bug] [regression]

  Behobene Regression, die durch die gerade veröffentlichte Performance-Korrektur in #6550 verursacht wurde, bei der ein query.join() zu einer Beziehung einen AttributeError erzeugen konnte, wenn die Abfrage nur auf Nicht-ORM-Strukturen angewendet wurde, ein eher ungewöhnliches Aufrufverhalten.

  Referenzen: #6558

1.4.16

Veröffentlicht: 28. Mai 2021

general

• [general] [bug]

  Verschiedene Deprecation-Warnungen behoben, die ab Python-Version 3.10.0b1 auftraten.

  Referenzen: #6540, #6543

orm

• [orm] [bug]

  Behobenes Problem bei der Verwendung des Parameters relationship.cascade_backrefs auf False gesetzt, was gemäß cascade_backrefs-Verhalten wird für die Entfernung in 2.0 als veraltet markiert zum Standardverhalten in SQLAlchemy 2.0 wird. Das Hinzufügen des Elements zu einer Sammlung, die Eindeutigkeit herstellt, wie z. B. set oder dict, löste kein Cascade-Ereignis aus, wenn das Objekt bereits über den Backref in dieser Sammlung vorhanden war. Diese Korrektur stellt eine grundlegende Änderung der Sammlungsmechanismen dar, indem ein neuer Ereigniszustand eingeführt wird, der bei einer Sammlungsänderung ausgelöst werden kann, auch wenn keine Nettoänderung an der Sammlung erfolgt. Die Aktion wird nun mithilfe eines neuen Ereignishooks AttributeEvents.append_wo_mutation() durchgeführt.

  Referenzen: #6471

• [orm] [bug] [regression]

  Behobene Regression bei der Klauselanpassung von benannten ORM-Verbundelementen, wie z. B. Single-Table-Inheritance-Diskriminatorausdrücken mit Bedingern oder CASE-Ausdrücken, die dazu führen konnte, dass aliasierte Ausdrücke, wie sie in ORM-Join/joinedload-Operationen verwendet werden, nicht korrekt angepasst wurden, z. B. durch Verweis auf die falsche Tabelle in der ON-Klausel eines Joins.

  Diese Änderung verbessert auch einen Performance-Boost, der bei der Invokation von Select.join() mit einem ORM-Attribut als Ziel auftrat.

  Referenzen: #6550

• [orm] [bug] [regression]

  Behobene Regression, bei der die vollständige Kombination aus Joined-Inheritance, globalem with_polymorphic, selbstreferenzieller Beziehung und Joined-Loading nicht in der Lage war, eine Abfrage mit dem Geltungsbereich von Lazy Loads und Object Refresh-Operationen zu erzeugen, die auch versuchten, den Joined Loader zu rendern.

  Referenzen: #6495

• [orm] [bug]

  Verbesserte die Bindungsauflösungsregeln für Session.execute(), so dass, wenn eine Nicht-ORM-Anweisung wie ein insert()-Konstrukt dennoch gegen ORM-Objekte aufgebaut wird, das ORM-Entität im größtmöglichen Umfang zur Auflösung der Bindung verwendet wird, z. B. für eine Session, die eine Bindungskarte für eine gemeinsame Oberklasse eingerichtet hat, ohne dass spezifische Mapper oder Tabellen in der Karte genannt sind.

  Referenzen: #6484

engine

• [engine] [bug]

  Behobenes Problem, bei dem ein @-Zeichen im Datenbankteil einer URL nicht korrekt interpretiert wurde, wenn die URL auch einen Abschnitt mit Benutzername:Passwort enthielt.

  Referenzen: #6482

• [engine] [bug]

  Behobenes langjähriges Problem mit URL, bei dem Abfrageparameter nach dem Fragezeichen nicht korrekt analysiert wurden, wenn die URL keinen Datenbankteil mit einem Backslash enthielt.

  Referenzen: #6329

sql

• [sql] [bug] [regression]

  Behobene Regression in der dynamischen Laderstrategie und relationship() im Allgemeinen, bei der der Parameter relationship.order_by als mutable Liste gespeichert wurde, die dann beim Kombinieren mit zusätzlichen „order_by“-Methoden, die auf dem dynamischen Query-Objekt verwendet wurden, mutiert werden konnte, was dazu führte, dass die ORDER BY-Kriterien sich wiederholend vergrößerten.

  Referenzen: #6549

mssql

• [mssql] [usecase]

  Unterstützung für ein CTE-Konstrukt als direktes Ziel eines delete()-Konstrukts implementiert, d.h. „WITH … AS cte DELETE FROM cte“. Dies scheint ein nützliches Merkmal von SQL Server zu sein.

  Referenzen: #6464

misc

• [bug] [ext]

  Behobene Deprecation-Warnung, die bei der Verwendung von automap_base() ohne Übergabe einer bestehenden Base ausgegeben wurde.

  Referenzen: #6529

• [bug] [pep484]

  PEP484-Typen aus dem Code entfernt. Die aktuelle Anstrengung konzentriert sich auf das Stub-Paket, und das Vorhandensein von Typisierungen an zwei Stellen verschlimmert die Situation, da die Typen im SQLAlchemy-Quellcode normalerweise veraltet waren im Vergleich zu der Version in den Stubs.

  Referenzen: #6461

• [bug] [ext] [regression]

  Behobene Regression in der sqlalchemy.ext.instrumentation-Erweiterung, die die vollständige Deaktivierung der Instrumentierung verhinderte. Diese Korrektur umfasst sowohl eine 1.4-Regression als auch eine Korrektur für ein verwandtes Problem, das bereits in 1.3 bestand. Im Rahmen dieser Änderung hat die Klasse sqlalchemy.ext.instrumentation.InstrumentationManager nun eine neue Methode unregister(), die die vorherige Methode dispose() ersetzt, die ab Version 1.4 nicht mehr aufgerufen wurde.

  Referenzen: #6390

1.4.15

Veröffentlicht: 11. Mai 2021

general

• [general] [feature]

  Ein neuer Ansatz wurde für das Warnsystem in SQLAlchemy angewendet, um die geeignete Stapelposition für jede Warnung dynamisch vorherzusagen. Dies ermöglicht eine einfachere Auswertung der Quelle von SQLAlchemy-generierten Warnungen und Deprecation-Warnungen, da die Warnung die Quellzeile im Code des Endbenutzers anzeigt und nicht aus einer beliebigen Ebene im eigenen Quellcode von SQLAlchemy.

  Referenzen: #6241

orm

• [orm] [bug] [regression]

  Zusätzliche Regression behoben, die durch die gerade veröffentlichte Funktion „eager loaders run on unexpire“ #1763 verursacht wurde. Die Funktion wurde für eine contains_eager() Eagerload-Option ausgeführt, wenn die contains_eager() an eine weitere Eagerloader-Option gekettet war. Dies führte zu einer fehlerhaften Abfrage, da die ursprünglichen abfragegebundenen Join-Kriterien nicht mehr vorhanden waren.

  Referenzen: #6449

• [orm] [bug]

  Behobenes Problem in der Subquery Loader Strategie, das das Caching verhinderte. Dies wäre in den Protokollen als „generated“ statt „cached“ für alle ausgegebenen Subqueryload-SQLs sichtbar gewesen, was durch Übersättigung des Caches mit neuen Schlüsseln die Gesamtleistung beeinträchtigt hätte; außerdem hätte dies zu „LRU size alert“-Warnungen geführt.

  Referenzen: #6459

sql

• [sql] [bug]

  Angepasste die Logik, die als Teil von #6397 in 1.4.12 hinzugefügt wurde, so dass die interne Mutation des BindParameter-Objekts während der Klauselerstellung erfolgt, wie es zuvor der Fall war, anstatt während der Kompilierungsphase. In letzterem Fall führte die Mutation immer noch zu Seiteneffekten gegen das eingehende Konstrukt und konnte zusätzlich andere interne Mutationsroutinen stören.

  Referenzen: #6460

mysql

• [mysql] [bug] [documentation]

  Unterstützung für den Parameter ssl_check_hostname= in mysql-Verbindungs-URIs hinzugefügt und die Dokumentation des mysql-Dialekts bezüglich sicherer Verbindungen aktualisiert. Ursprüngliche Pull-Anfrage von Jerry Zhao.

  Referenzen: #5397

1.4.14

Veröffentlicht: 6. Mai 2021

orm

• [orm] [bug] [regression]

  Behobene Regression, die die lazy='dynamic' Laderstrategie in Verbindung mit einem abgetrennten Objekt betraf. Das frühere Verhalten war, dass der dynamische Lader bei Aufruf von Methoden wie .all() leere Listen für abgetrennte Objekte ohne Fehler zurückgab. Dieses Verhalten wurde wiederhergestellt; es wird jedoch jetzt eine Warnung ausgegeben, da dies nicht das korrekte Ergebnis ist. Andere dynamische Lader-Szenarien lösen weiterhin korrekt DetachedInstanceError aus.

  Referenzen: #6426

engine

• [engine] [usecase] [orm]

  Konsistentes Verhalten bei der Verwendung von .commit() oder .rollback() innerhalb eines bestehenden .begin() Context Managers wurde angewendet, mit der zusätzlichen Möglichkeit, SQL innerhalb des Blocks nach dem Commit oder Rollback auszugeben. Diese Änderung setzt die in #6155 eingeführte Änderung fort, bei der die Verwendung von „rollback“ innerhalb eines .begin() Context Manager Blocks vorgeschlagen wurde.

  • Das Aufrufen von .commit() oder .rollback() ist nun fehler- und warnungsfrei in allen Bereichen erlaubt, einschließlich des Legacy- und zukünftigen Engine, ORM Session, asyncio AsyncEngine. Zuvor hat die Session dies nicht zugelassen.

  • Der verbleibende Bereich des Context Managers wird dann geschlossen; wenn der Block endet, wird geprüft, ob die Transaktion bereits beendet wurde, und wenn ja, wird der Block ohne Aktion zurückgegeben.

  • Es wird nun **ein Fehler** ausgelöst, wenn nach dem Aufruf von .commit() oder .rollback() nachfolgend SQL beliebiger Art im Block ausgegeben wird. Der Block sollte geschlossen werden, da der Zustand des ausführbaren Objekts in diesem Zustand sonst undefiniert wäre.

  Referenzen: #6288

• [engine] [bug] [regression]

  Ein Deprecationspfad für den Aufruf der Methode CursorResult.keys() für eine Anweisung, die keine Zeilen zurückgibt, wurde etabliert, um Legacy-Muster des Pakets „records“ sowie andere nicht migrierte Anwendungen zu unterstützen. Zuvor löste dies bedingungslos ResourceClosedException aus, genauso wie beim Abrufen von Zeilen. Obwohl dies das korrekte Verhalten für die Zukunft ist, gibt das Objekt LegacyCursorResult in diesem Fall nun eine leere Liste für .keys() zurück, wie es auch in 1.3 der Fall war, und gibt gleichzeitig eine 2.0 Deprecations-Warnung aus. Die _cursor.CursorResult, die bei der Verwendung einer 2.0-Style „future“-Engine verwendet wird, wird weiterhin wie bisher ausgelöst.

  Referenzen: #6427

sql

• [sql] [bug] [regression]

  Behobene Regression, die durch die gerade erfolgte Änderung „leeres IN“ in #6397 1.4.12 verursacht wurde, bei der der Ausdruck für den „not in“-Anwendungsfall in Klammern gesetzt werden muss, andernfalls stört die Bedingung andere Filterkriterien.

  Referenzen: #6428

• [sql] [bug] [regression]

  Die Klasse TypeDecorator gibt nun eine Warnung aus, wenn sie in der SQL-Kompilierung mit Caching verwendet wird, es sei denn, das Flag .cache_ok ist auf True oder False gesetzt. Ein neues Klassenattribut TypeDecorator.cache_ok kann gesetzt werden, das als Indikator dafür dient, dass alle an das Objekt übergebenen Parameter als Cache-Schlüssel verwendet werden können, wenn es auf True gesetzt ist; False bedeutet, dass dies nicht der Fall ist.

  Referenzen: #6436

1.4.13

Veröffentlicht: 3. Mai 2021

orm

• [orm] [bug] [regression]

  Behobene Regression in der selectinload Loader-Strategie, die dazu führte, dass ihr interner Zustand falsch zwischengespeichert wurde, wenn Beziehungen gehandhabt wurden, die über mehr als eine Spalte verbunden waren, z. B. bei Verwendung eines zusammengesetzten Fremdschlüssels. Die fehlerhafte Zwischenspeicherung führte dann zum Fehlschlagen anderer, nicht verwandter Laderoperationen.

  Referenzen: #6410

• [orm] [bug] [regression]

  Behobene Regression, bei der Query.filter_by() nicht funktionierte, wenn die führende Entität eine SQL-Funktion oder ein anderer Ausdruck war, der von der fraglichen primären Entität abgeleitet war, anstatt einer einfachen Entität oder Spalte dieser Entität. Zusätzlich wurde das Verhalten von Select.filter_by() insgesamt verbessert, um auch in einem Nicht-ORM-Kontext mit Spaltenausdrücken zu funktionieren.

  Referenzen: #6414

• [orm] [bug] [regression]

  Behobene Regression, bei der die Verwendung von selectinload() und subqueryload() zum Laden eines zweistufig tiefen Pfads zu einem Attributfehler führte.

  Referenzen: #6419

• [orm] [bug] [regression]

  Behobene Regression, bei der die Verwendung der noload() Loader-Strategie in Verbindung mit einer „dynamischen“ Beziehung zu einem Attributfehler führte, da die noload-Strategie versuchte, sich auf den dynamischen Lader anzuwenden.

  Referenzen: #6420

engine

• [engine] [bug] [regression]

  Wiederherstellung eines Legacy-Transaktionsverhaltens, das unbeabsichtigt aus der Connection entfernt wurde, da es in früheren Versionen nie als bekannter Anwendungsfall getestet wurde. Das Aufrufen der Methode Connection.begin_nested(), wenn keine Transaktion vorhanden ist, erstellte überhaupt keinen SAVEPOINT, sondern startete stattdessen eine äußere Transaktion und gab ein RootTransaction-Objekt anstelle eines NestedTransaction-Objekts zurück. Dieses RootTransaction sendete dann ein echtes COMMIT an die Datenbankverbindung, wenn es committet wurde. Zuvor war das Verhalten im 2.0-Stil in allen Fällen vorhanden, die eine Transaktion automatisch starteten, aber nicht committeten, was eine Verhaltensänderung darstellt.

  Bei Verwendung eines Verbindungs-Objekts im 2.0-Stil ist das Verhalten gegenüber früheren 1.4-Versionen unverändert. Das Aufrufen von Connection.begin_nested() startet die äußere Transaktion automatisch ("autobegin"), wenn sie noch nicht vorhanden ist, und sendet dann wie angewiesen einen SAVEPOINT und gibt das NestedTransaction-Objekt zurück. Die äußere Transaktion wird durch Aufrufen von Connection.commit() committet, ebenso wie bei der Verwendung im "Commit-as-you-go"-Stil.

  Im Nicht-"future"-Modus wird das alte Verhalten zwar wiederhergestellt, aber es wird auch eine 2.0-Deprecation-Warnung ausgegeben, da es sich um ein Legacy-Verhalten handelt.

  Referenzen: #6408

asyncio

• [asyncio] [bug] [regression]

  Behoben eine Regression, die durch #6337 eingeführt wurde und die ein asyncio.Lock erzeugte, das an die falsche Schleife gebunden werden konnte, wenn die asynchrone Engine instanziiert wurde, bevor eine asyncio-Schleife gestartet wurde, was unter bestimmten Umständen zu einer asyncio-Fehlermeldung führte, wenn versucht wurde, die Engine zu verwenden.

  Referenzen: #6409

postgresql

• [postgresql] [usecase]

  Unterstützung für serverseitige Cursor im pg8000-Dialekt für PostgreSQL hinzugefügt. Dies ermöglicht die Verwendung der Option Connection.execution_options.stream_results.

  Referenzen: #6198

1.4.12

Veröffentlicht: 29. April 2021

orm

• [orm] [bug]

  Problem in Session.bulk_save_objects() bei Verwendung mit persistenten Objekten behoben, die den Primärschlüssel von Mappings nicht verfolgen konnten, bei denen der Spaltenname des Primärschlüssels vom Attributnamen abwich.

  Diese Änderung wird auch **zurückportiert** auf: 1.3.25

  Referenzen: #6392

• [orm] [bug] [caching] [regression]

  Kritische Regression behoben, bei der die Verfolgung gebundener Parameter, wie sie im SQL-Caching-System verwendet wird, möglicherweise nicht alle Parameter für den Fall verfolgte, dass derselbe SQL-Ausdruck mit einem Parameter in einer ORM-bezogenen Abfrage verwendet wurde, die eine Funktion wie Klassenvererbung nutzte, die dann in einem umschließenden Ausdruck eingebettet war, der diesen Ausdruck mehrfach verwendete, z. B. eine UNION. Das ORM kopierte einzelne SELECT-Anweisungen als Teil der Kompilierung mit Klassenvererbung, was dann in die umschließende Anweisung eingebettet nicht alle Parameter berücksichtigen konnte. Die Logik, die diesen Zustand verfolgt, wurde angepasst, um für mehrere Kopien eines Parameters zu funktionieren.

  Referenzen: #6391

• [orm] [bug]

  Zwei verschiedene Probleme behoben, die hauptsächlich hybrid_property betrafen und bei gängigen Fehlkonfigurationen auftraten, die in 1.3 stillschweigend ignoriert wurden und nun in 1.4 fehlschlugen, bei denen die "expression"-Implementierung einen Nicht-ClauseElement wie einen booleschen Wert zurückgab. Bei beiden Problemen bestand das Verhalten von 1.3 darin, die Fehlkonfiguration stillschweigend zu ignorieren und letztendlich zu versuchen, den Wert als SQL-Ausdruck zu interpretieren, was zu einer fehlerhaften Abfrage führte.

  • Problem behoben bezüglich der Interaktion des Attributsystems mit hybrid_property, bei der, wenn die Methode __clause_element__() des Attributs ein Nicht-ClauseElement-Objekt zurückgab, ein internes AttributeError dazu führte, dass das Attribut die Funktion expression auf der hybrid_property selbst zurückgab, da der Attributfehler gegen den Namen .expression erfolgte, was die Methode __getattr__() als Fallback aufrief. Dies löst nun explizit aus. In 1.3 wurde das Nicht-ClauseElement direkt zurückgegeben.

  • Problem mit SQL-Argument-Koerzionen behoben, bei denen das Übergeben des falschen Objekttyps an Methoden, die Spaltenausdrücke erwarteten, fehlschlug, wenn das Objekt überhaupt kein SQLAlchemy-Objekt war, wie z. B. eine Python-Funktion, in Fällen, in denen das Objekt nicht nur in einen gebundenen Wert koerziert wurde. Auch hier hatte 1.3 kein umfassendes Argument-Koerzionssystem, so dass dieser Fall ebenfalls stillschweigend durchging.

  Referenzen: #6350

• [orm] [bug]

  Problem behoben, bei dem die Verwendung eines Select als Unterabfrage in einem ORM-Kontext die Select-Anweisung vor Ort modifizierte, um Eagerloads für dieses Objekt zu deaktivieren, was dann dazu führte, dass dieselbe Select-Anweisung nicht Eagerloads, wenn sie dann in einem Top-Level-Ausführungskontext wiederverwendet wurde.

  Referenzen: #6378

• [orm] [bug] [regression]

  Problem behoben, bei dem das neue Verhalten der automatischen Transaktionseröffnung in dem Fall, dass ein bestehendes persistentes Objekt eine Attributänderung hat, nicht "automatisch eröffnet" wurde, was sich auf das Verhalten von Session.rollback() auswirkte, da kein Snapshot zum Zurückrollen erstellt wurde. Die "Attributänderungs"-Mechanismen wurden aktualisiert, um sicherzustellen, dass eine "automatische Eröffnung" (die keine Datenbankarbeit ausführt) erfolgt, wenn persistente Attribute geändert werden, genauso wie beim Aufruf von Session.add(). Dies ist eine Regression, da in 1.3 die rollback()-Methode immer eine Transaktion zum Zurückrollen hatte und jedes Mal ablief.

  Referenzen: #6359, #6360

• [orm] [bug] [regression]

  Regression im ORM behoben, bei der die Verwendung von hybrid property zur Angabe eines Ausdrucks aus einer anderen Entität die Spaltenbenennungslogik im ORM verwirrte und versuchte, den Namen des Hybrids von dieser anderen Klasse abzuleiten, was zu einem Attributfehler führte. Die besitzende Klasse des Hybridattributs wird nun zusammen mit dem Namen verfolgt.

  Referenzen: #6386

• [orm] [bug] [regression]

  Regression in hybrid_property behoben, bei der ein Hybrid, der sich auf eine SQL-Funktion bezog, einen AttributeError auslöste, wenn versucht wurde, einen Eintrag für die .c-Sammlung einer Unterabfrage in einigen Fällen zu generieren; dies beeinträchtigte unter anderem die Verwendung in Fällen wie Query.count().

  Referenzen: #6401

• [orm] [bug] [dataclasses]

  Der deklarative Scan für Dataclasses wurde angepasst, sodass das Vererbungsverhalten von declared_attr(), das auf einem Mixin definiert wurde, wenn die neue Form verwendet wird, bei der es sich innerhalb eines dataclasses.field()-Konstrukts und nicht als deskriptor-Attribut auf der Klasse befindet, den Fall korrekt berücksichtigt, wenn die zu mappende Zielklasse eine Unterklasse einer vorhandenen gemappten Klasse ist, die dieses declared_attr() bereits abgebildet hat und daher nicht erneut auf diese Klasse angewendet werden sollte.

  Referenzen: #6346

• [orm] [bug]

  Problem mit der (in 1.4 veralteten) Methode ForeignKeyConstraint.copy() behoben, die bei Aufruf mit dem Argument schema einen Fehler verursachte.

  Referenzen: #6353

engine

• [engine] [bug]

  Problem behoben, bei dem die Verwendung einer expliziten Sequence ein inkonsistentes "Inline"-Verhalten für ein Insert-Konstrukt mit mehreren Wertesätzen erzeugte; die erste Sequenz war Inline, die nachfolgenden wurden jedoch "vorab ausgeführt", was zu inkonsistenten Sequenzreihenfolgen führte. Die Sequenzausdrücke sind jetzt vollständig Inline.

  Referenzen: #6361

sql

• [sql] [bug]

  Der Ausdruck "EMPTY IN" wurde überarbeitet, um nicht mehr auf Unterabfragen zu setzen, da dies zu Kompatibilitäts- und Leistungsproblemen führte. Der neue Ansatz für ausgewählte Datenbanken nutzt einen NULL-zurückgebenden IN-Ausdruck, kombiniert mit dem üblichen "1 != 1" oder "1 = 1"-Ausdruck, der mit AND oder OR angehängt wird. Der Ausdruck ist jetzt Standard für alle Backends außer SQLite, das immer noch Kompatibilitätsprobleme mit Tupel-"IN" für ältere SQLite-Versionen hatte.

  Drittanbieter-Dialekte können immer noch überschreiben, wie der Ausdruck "leere Menge" gerendert wird, indem sie eine neue Compiler-Methode def visit_empty_set_op_expr(self, type_, expand_op) implementieren, die Vorrang vor der vorhandenen Methode def visit_empty_set_expr(self, element_types) hat, die erhalten bleibt.

  Referenzen: #6258, #6397

• [sql] [bug] [regression]

  Regression behoben, bei der die Verwendung des text()-Konstrukts innerhalb der Spaltenklausel eines Select-Konstrukts, das besser mit literal_column() behandelt werden sollte, dennoch Konstrukte wie union() daran hinderten, korrekt zu funktionieren. Andere Anwendungsfälle, wie die Konstruktion von Unterabfragen, funktionieren weiterhin wie in früheren Versionen, wo das text()-Konstrukt stillschweigend aus der Sammlung exportierter Spalten weggelassen wurde. Repariert auch ähnliche Verwendungen im ORM.

  Referenzen: #6343

• [sql] [bug] [regression]

  Regression behoben, bei der die Verwendung von Legacy-Methoden wie Select.append_column() dazu führte, dass interne Assertions fehlschlugen.

  Referenzen: #6261

• [sql] [bug] [regression]

  Regression behoben, verursacht durch #5395, bei der die erneute Prüfung auf Sequenzen in select() nun zu Fehlern bei der 2.0-Stil-Abfrage mit einer gemappten Klasse führte, die auch eine __iter__()-Methode hatte. Die Prüfung wurde weiter angepasst, um dies sowie einige andere interessante __iter__()-Szenarien zu berücksichtigen.

  Referenzen: #6300

schema

• [schema] [bug] [mariadb] [mysql] [oracle] [postgresql]

  Sicherstellen, dass der MySQL- und MariaDB-Dialekt das Identity-Konstrukt beim Rendern des Schlüsselworts AUTO_INCREMENT in einer CREATE TABLE-Anweisung ignoriert.

  Der Oracle- und PostgreSQL-Compiler wurde aktualisiert, um Identity nicht zu rendern, wenn die Datenbankversion dies nicht unterstützt (Oracle < 12 und PostgreSQL < 10). Zuvor wurde es unabhängig von der Datenbankversion gerendert.

  Referenzen: #6338

postgresql

• [postgresql] [bug]

  Ein sehr altes Problem behoben, bei dem der Datentyp Enum den MetaData.schema-Parameter eines MetaData-Objekts nicht erbte, wenn dieses Objekt über Enum.metadata an Enum übergeben wurde.

  Referenzen: #6373

sqlite

• [sqlite] [usecase]

  Standardmäßig wird SingletonThreadPool für In-Memory-SQLite-Datenbanken verwendet, die mit URI-Dateinamen erstellt wurden. Zuvor war der Standardpool der NullPool, der das Teilen derselben Datenbank zwischen mehreren Engines verhinderte.

  Referenzen: #6379

mssql

• [mssql] [bug] [schema]

  Unterstützung für TypeEngine.as_generic() für sqlalchemy.dialects.mysql.BIT-Spalten hinzugefügt und diese auf Boolean abgebildet.

  Referenzen: #6345

• [mssql] [bug] [regression]

  Regression behoben, verursacht durch #6306, das Unterstützung für DateTime(timezone=True) hinzufügte, wobei das frühere Verhalten des pyodbc-Treibers, tzinfo aus einem zeitzeitzonenbewussten Datum beim Einfügen in eine zeitzeitzonenunbewusste DATETIME-Spalte implizit zu entfernen, verloren ging, was zu einem SQL Server-Fehler führte, wenn zeitzeitzonenbewusste Datums-/Zeitobjekte in zeitzeitzonenunbewusste Datenbankspalten eingefügt wurden.

  Referenzen: #6366

1.4.11

Veröffentlicht: 21. April 2021

orm declarative

• [orm] [declarative] [bug] [regression]

  Regression behoben, bei der Änderungen zur Unterstützung von Python-Dataclasses unbeabsichtigte Auswirkungen hatten, sodass eine ORM-gemappte Klasse die Methode __new__() nicht erfolgreich überschreiben konnte.

  Referenzen: #6331

engine

• [engine] [bug] [regression]

  Kritische Regression behoben, verursacht durch die Änderung in #5497, bei der die Verbindungs-Pool-"init"-Phase nicht mehr innerhalb einerMutex-Isolation stattfand, wodurch andere Threads mit dem nicht initialisierten Dialekt fortfahren konnten, was sich dann auf die Kompilierung von SQL-Anweisungen auswirken konnte.

  Referenzen: #6337

1.4.10

Veröffentlicht: 20. April 2021

orm

• [orm] [usecase]

  Einige Verhaltensweisen, die in #6232 repariert wurden, wurden geändert, bei denen die immediateload-Lade-Strategie keine rekursiven Schleifen mehr durchlief; die Änderung besteht darin, dass ein Eager Load (joinedload, selectinload oder subqueryload) von A->bs->B, das dann immediateload für ein einfaches ManyToOne B->a->A angibt, das sich in der Identity Map befindet, B->A füllt, sodass dieses Attribut zurück-gefüllt wird, wenn die Sammlung von A/A.bs geladen werden. Dies ermöglicht die Funktionalität der Objekte im getrennten Zustand.

• [orm] [bug]

  Fehler in der neuen Funktion with_loader_criteria() behoben, bei der die Verwendung einer Mixin-Klasse mit declared_attr() für ein Attribut, auf das innerhalb des benutzerdefinierten Lambdas zugegriffen wurde, eine Warnung bezüglich der Verwendung eines nicht gemappten deklarierten Attributs ausgab, wenn der Lambda-Aufruf zuerst initialisiert wurde. Diese Warnung wird nun durch spezielle Instrumentierung für diesen Lambda-Initialisierungsschritt verhindert.

  Referenzen: #6320

• [orm] [bug] [regression]

  Zusätzliche Regression behoben, verursacht durch die Funktion "Eagerloader beim Aktualisieren", die in #1763 hinzugefügt wurde, bei der die Aktualisierungsoperation historisch populate_existing setzte, was angesichts der neuen Funktion nun ausstehende Änderungen an eagegeladenen Objekten überschreibt, wenn autoflush falsch ist. Das Flag populate_existing wurde für diesen Fall deaktiviert und eine spezifischere Methode verwendet, um sicherzustellen, dass die richtigen Attribute aktualisiert werden.

  Referenzen: #6326

• [orm] [bug] [result]

  Problem behoben, bei der Verwendung der Ausführung im 2.0-Stil die Verwendung von Result.scalar_one() oder Result.scalar_one_or_none() nach dem Aufrufen von Result.unique() verhinderte, für den Fall, dass das ORM ohnehin eine einzeilige Zeile zurückgab.

  Referenzen: #6299

sql

• [sql] [bug]

  Problem im SQL-Compiler behoben, bei dem die für ein Values-Konstrukt eingerichteten gebundenen Parameter nicht korrekt positionsbezogen verfolgt wurden, wenn sie sich innerhalb eines CTE befanden. Dies beeinträchtigte Datenbanktreiber, die VALUES + CTEs unterstützen und Positions-Parameter verwenden, insbesondere SQL Server sowie asyncpg. Die Korrektur repariert auch die Unterstützung für Compiler-Flags wie literal_binds.

  Referenzen: #6327

• [sql] [bug]

  Probleme im Zusammenhang mit benutzerdefinierten Funktionen und anderen willkürlichen Ausdruckskonstrukten, die innerhalb der SQLAlchemy-Mechanismen zur Spaltenbenennung versucht haben, str(obj) zu verwenden, um eine Zeichenfolgendarstellung als anonymen Spaltennamen in der .c-Sammlung einer Unterabfrage zu erhalten, wurden repariert und gefestigt. Dies ist ein sehr altes Verhalten, das schlecht performt und viele Probleme verursacht. Daher wurde es überarbeitet, um keine Kompilierung mehr durchzuführen, indem spezifische Methoden auf FunctionElement eingerichtet wurden, um diesen Fall zu behandeln, da SQL-Funktionen der einzige Anwendungsfall sind, bei dem er auftrat. Eine Auswirkung dieses Verhaltens ist, dass eine unbenannte Spaltenexpression ohne ableitbaren Namen in der .c-Sammlung einer Unterabfrage eine willkürliche Bezeichnung mit dem Präfix "_no_label" erhält; diese wurden zuvor entweder als generische Stringifikation dieses Ausdrucks oder als internes Symbol dargestellt.

  Referenzen: #6256

schema

• [schema] [bug]

  Problem behoben, bei dem next_value() seinen Typ nicht vom entsprechenden Sequence ableitete, sondern auf Integer fest kodiert war. Der spezifische numerische Typ wird nun verwendet.

  Referenzen: #6287

mypy

• [mypy] [bug]

  Behobenes Problem, bei dem das mypy-Plugin eine explizite Mapped-Annotation in Verbindung mit einem relationship(), das auf eine Klasse mit String-Namen verweist, nicht korrekt interpretieren konnte; die korrekte Annotation wurde zu einer weniger spezifischen herabgestuft, was zu Tippfehlern führte.

  Referenzen: #6255

mssql

• [mssql] [usecase]

  Der Parameter DateTime.timezone wird nun, wenn er auf True gesetzt ist, den Spaltentyp DATETIMEOFFSET für SQL Server verwenden, wenn DDL emittiert wird, anstelle von DATETIME, bei dem das Flag stillschweigend ignoriert wurde.

  Referenzen: #6306

misc

• [bug] [declarative] [regression]

  Behobenes Problem mit instrument_declarative(), das eine nicht existierende Registry-Methode aufgerufen hat.

  Referenzen: #6291

1.4.9

Veröffentlicht: 17. April 2021

orm

• [orm] [usecase]

  Etablierte Unterstützung für synonym() in Verbindung mit hybriden Eigenschaften. AssocationProxies werden vollständig eingerichtet, einschließlich der Tatsache, dass Synonyme eingerichtet werden können, die auf diese Konstrukte verweisen und vollständig funktionieren. Dies war ein Verhalten, das zuvor semi-explizit verboten war. Da es jedoch nicht in jedem Szenario zu Fehlern kam, wurde explizite Unterstützung für Assocation Proxies und Hybride hinzugefügt.

  Referenzen: #6267

• [orm] [bug] [performance] [regression] [sql]

  Kritisches Performance-Problem behoben, bei dem die Traversierung einer select()-Konstruktion ein repetitives Produkt der repräsentierten FROM-Klauseln durchlaufen würde, da diese jeweils in der Spaltenklausel referenziert wurden; bei einer Reihe von verschachtelten Subqueries mit vielen Spalten konnte dies zu einer großen Verzögerung und erheblichem Speicherwachstum führen. Diese Traversierung wird von einer Vielzahl von SQL- und ORM-Funktionen verwendet, einschließlich der ORM Session, wenn diese für "table-per-bind" konfiguriert ist, was zwar kein gängiger Anwendungsfall ist, aber anscheinend das ist, was Flask-SQLAlchemy fest kodiert verwendet. Daher wirkt sich das Problem auf Flask-SQLAlchemy-Benutzer aus. Die Traversierung wurde repariert, um FROM-Klauseln zu vereinheitlichen, was im Wesentlichen das war, was bei der Architektur vor 1.4 implizit geschah.

  Referenzen: #6304

• [orm] [bug] [regression]

  Behobene Regression, bei der ein Attribut, das auf ein synonym() abgebildet ist, nicht in Spalten-Loader-Optionen wie load_only() verwendet werden konnte.

  Referenzen: #6272

sql

• [sql] [bug] [regression]

  Behobene Regression, bei der eine leere In-Anweisung für ein Tupel zu einem Fehler führte, wenn sie mit der Option literal_binds=True kompiliert wurde.

  Referenzen: #6290

postgresql

• [postgresql] [bug] [regression] [sql]

  Behobener Argumentfehler in den Standard- und PostgreSQL-Kompilierern, der eine UPDATE..FROM- oder DELETE..FROM..USING-Anweisung beeinträchtigte, die dann als CTE ausgewählt wurde.

  Referenzen: #6303

1.4.8

Veröffentlicht: 15. April 2021

orm

• [orm] [bug] [regression]

  Cache-Leak behoben, der die Loader-Option with_expression() betraf, bei der der angegebene SQL-Ausdruck nicht korrekt als Teil des Cache-Schlüssels berücksichtigt wurde.

  Zusätzlich wurde eine Regression im Zusammenhang mit der entsprechenden Funktion query_expression() behoben. Obwohl der Fehler technisch auch in 1.3 vorhanden war, wurde er erst in 1.4 sichtbar. Der Wert "default expr" von null() wurde gerendert, wenn er nicht benötigt wurde, und zusätzlich wurde er auch nicht korrekt angepasst, wenn der ORM Anweisungen umschrieb, wie z. B. beim Joined Eager Loading. Die Korrektur stellt sicher, dass "Singleton"-Ausdrücke wie NULL und true nicht auf Spalten in ORM-Anweisungen "abgebildet" werden, und stellt außerdem sicher, dass eine query_expression() ohne Standardausdruck nicht in der Anweisung gerendert wird, wenn keine with_expression() verwendet wird.

  Referenzen: #6259

• [orm] [bug]

  Problem bei der neuen Funktion von Session.refresh() behoben, die durch #1763 eingeführt wurde, bei der auch eager geladene Beziehungen aktualisiert werden. Die Lade-Strategien lazy="raise" und lazy="raise_on_sql" würden die Loader-Strategie immediateload() beeinträchtigen und somit die Funktion für Beziehungen brechen, die mit selectinload(), subqueryload() geladen wurden.

  Referenzen: #6252

engine

• [engine] [bug]

  Die Methode Dialect.has_table() löst nun eine informative Ausnahme aus, wenn ihr keine Verbindung übergeben wird, da dieses fehlerhafte Verhalten anscheinend häufig vorkommt. Diese Methode ist nicht für die externe Verwendung außerhalb eines Dialekts vorgesehen. Bitte verwenden Sie die Methode Inspector.has_table() oder für die Kompatibilität mit älteren SQLAlchemy-Versionen die Methode Engine.has_table().

sql

• [sql] [feature]

  Das von CursorResult.inserted_primary_key zurückgegebene Tupel ist nun ein Row-Objekt mit einer Named-Tuple-Schnittstelle über der bestehenden Tupel-Schnittstelle.

  Referenzen: #3314

• [sql] [bug] [regression]

  Behobene Regression, bei der das BindParameter-Objekt für einen IN-Ausdruck (d. h. unter Verwendung des "Post-Compile"-Features in 1.4) nicht richtig gerendert wurde, wenn das Objekt aus einem internen Klonvorgang oder einem Pickle-Vorgang kopiert wurde und der Parametername Leerzeichen oder andere Sonderzeichen enthielt.

  Referenzen: #6249

• [sql] [bug] [regression] [sqlite]

  Behobene Regression, bei der die Einführung der INSERT-Syntax "INSERT... VALUES (DEFAULT)" auf einigen Backends nicht unterstützt wurde, die jedoch "INSERT..DEFAULT VALUES" unterstützen, einschließlich SQLite. Die beiden Syntaxen werden nun jeweils einzeln für jeden Dialekt unterstützt oder nicht unterstützt, z. B. unterstützt MySQL "VALUES (DEFAULT)", aber nicht "DEFAULT VALUES". Die Unterstützung für Oracle wurde ebenfalls aktiviert.

  Referenzen: #6254

mypy

• [mypy] [change]

  Mypy-Plugin aktualisiert, um nur die öffentliche Plugin-Schnittstelle des semantischen Analysators zu verwenden.

• [mypy] [bug]

  Überarbeitete Korrektur für OrderingList aus Version 1.4.7, die gegen die falsche API getestet wurde.

  Referenzen: #6205

asyncio

• [asyncio] [bug]

  Tippfehler behoben, der das Setzen des bind-Attributs einer AsyncSession auf den korrekten Wert verhinderte.

  Referenzen: #6220

mssql

• [mssql] [bug] [regression]

  Eine weitere Regression im selben Bereich wie bei #6173, #6184 behoben, bei der die Verwendung eines Wertes von 0 für OFFSET in Verbindung mit LIMIT bei SQL Server eine Anweisung mit "TOP" erzeugte, wie es in 1.3 der Fall war, aber aufgrund von Caching dann nicht mehr entsprechend auf andere OFFSET-Werte reagierte. Wenn der "0"-Wert nicht der erste war, war es in Ordnung. Als Korrektur wird die "TOP"-Syntax nun nur noch ausgegeben, wenn der OFFSET-Wert vollständig weggelassen wird, d.h. Select.offset() nicht verwendet wird. Beachten Sie, dass diese Änderung nun erfordert, dass bei Verwendung der Modifikatoren "with_ties" oder "percent" die Anweisung keinen OFFSET von Null angeben kann; sie muss nun vollständig weggelassen werden.

  Referenzen: #6265

1.4.7

Veröffentlicht: 9. April 2021

orm

• [orm] [bug] [regression]

  Behobene Regression, bei der die Loader-Strategie subqueryload() Unteroptionen, wie z. B. eine defer()-Option für eine Spalte, nicht korrekt berücksichtigen konnte, wenn der "Pfad" der subqueryload mehr als eine Ebene tief war.

  Referenzen: #6221

• [orm] [bug] [regression]

  Behobene Regression, bei der die Funktion merge_frozen_result(), die vom dogpile.caching-Beispiel verwendet wird, nicht in Tests enthalten war und aufgrund falscher interner Argumente fehlschlug.

  Referenzen: #6211

• [orm] [bug] [regression]

  Kritische Regression behoben, bei der die Session möglicherweise keine neue Transaktion "autobeginnt", wenn ein Flush ohne bestehende Transaktion auftrat, was die Session implizit in den Legacy-Autocommit-Modus versetzte, der die Transaktion committet. Die Session verfügt nun über eine Überprüfung, die diese Bedingung verhindert, und behebt zusätzlich das Flush-Problem.

  Darüber hinaus wurde ein Teil der mit #5226 vorgenommenen Änderung zurückgenommen, die Autoflush während einer "unexpire"-Operation ausführen kann, um dies im Falle einer Session, die den Legacy-Modus Session.autocommit verwendet, nicht tatsächlich zu tun, da dies einen Commit innerhalb einer Refresh-Operation verursacht.

  Referenzen: #6233

• [orm] [bug] [regression]

  Behobene Regression, bei der das ORM-Kompilierungsschema den Funktionsnamen einer hybriden Eigenschaft mit dem Attributnamen gleichsetzte, so dass ein AttributeError ausgelöst wurde, wenn versucht wurde, den korrekten Namen für jedes Element in einem Ergebnis-Tupel zu ermitteln. Ein ähnliches Problem besteht in 1.3, wirkt sich aber nur auf die Namen von Tupelzeilen aus. Die Korrektur hier fügt eine Prüfung hinzu, ob der Funktionsname des Hybrids tatsächlich im __dict__ der Klasse oder ihrer Oberklassen vorhanden ist, bevor dieser Name zugewiesen wird; andernfalls wird das Hybrid als "unbenannt" betrachtet und ORM-Ergebnis-Tupel verwenden das Benennungsschema des zugrunde liegenden Ausdrucks.

  Referenzen: #6215

• [orm] [bug] [regression]

  Kritische Regression behoben, die durch die neue Funktion verursacht wurde, die als Teil von #1763 hinzugefügt wurde: Eager-Loader werden bei "unexpire"-Operationen aufgerufen. Die neue Funktion verwendet die "immediateload"-Eager-Loader-Strategie als Ersatz für eine Sammlungslade-Strategie, die im Gegensatz zu den anderen "post-load"-Strategien keine rekursiven Aufrufe zwischen gegenseitig abhängigen Beziehungen berücksichtigte, was zu Rekursionsüberlauf-Fehlern führte.

  Referenzen: #6232

engine

• [engine] [bug] [regression]

  Das Verhalten des Row-Objekts bei der Wörterbuch-basierten Zugriff (d. h. Konvertierung in ein Dictionary mittels dict(row) oder Zugriff auf Mitglieder über Strings oder andere Objekte, z. B. row["some_key"]) wurde korrigiert, so dass es wie bei einem Dictionary funktioniert und keine TypeError mehr auslöst, wie es bei einem Tupel der Fall war, unabhängig davon, ob die C-Erweiterungen vorhanden sind oder nicht. Ursprünglich sollte dies eine 2.0-Deprecation-Warnung für den "nicht-zukunftsfähigen" Fall mit LegacyRow auslösen und TypeError für die "zukunftsfähige" Row-Klasse auslösen. Die C-Version von Row löste diese TypeError jedoch nicht aus, und um die Sache zu verkomplizieren, gibt die Methode Session.execute() nun in allen Fällen Row zurück, um die Konsistenz mit dem ORM-Ergebnisfall zu wahren. Daher sahen Benutzer ohne installierte C-Erweiterungen in diesem einzigen Fall ein anderes Verhalten für bestehenden Code im Stil vor 1.4.

  Daher bieten sowohl LegacyRow als auch Row Zugriff über String-Schlüssel und Unterstützung für dict(row), um das Upgrade-Schema zu mildern, da die meisten Benutzer bis 1.4.6 nicht mit dem strengeren Verhalten von Row konfrontiert waren. In allen Fällen wird die 2.0-Deprecation-Warnung ausgelöst, wenn SQLALCHEMY_WARN_20 aktiviert ist. Das Row-Objekt verwendet weiterhin Tupel-ähnliches Verhalten für __contains__, was wahrscheinlich die einzige bemerkenswerte Verhaltensänderung im Vergleich zu LegacyRow ist, abgesehen von der Entfernung der dictionary-ähnlichen Methoden values() und items().

  Referenzen: #6218

sql

• [sql] [bug] [regression]

  Das "erweiternde" Feature für ColumnOperators.in_()-Operationen wurde verbessert, um den Typ des Ausdrucks aus der rechten Liste der Elemente abzuleiten, wenn die linke Seite keinen expliziten Typ gesetzt hat. Dies ermöglicht es dem Ausdruck, String-Konvertierung und andere Dinge zu unterstützen. In 1.3 wurde "erweiternd" nicht automatisch für ColumnOperators.in_()-Ausdrücke verwendet, so dass diese Änderung in diesem Sinne eine Verhaltensregression behebt.

  Referenzen: #6222

• [sql] [bug]

  Der "stringify"-Compiler wurde korrigiert, um eine grundlegende String-Konvertierung eines "multirow" INSERT-Statements zu unterstützen, d. h. eines mit mehreren Tupeln nach dem VALUES-Schlüsselwort.

schema

• [schema] [bug] [regression]

  Behobene Regression, bei der die Verwendung eines Tokens im Wörterbuch Connection.execution_options.schema_translate_map, das Sonderzeichen wie Klammern enthielt, nicht richtig ersetzt wurde. Die Verwendung von eckigen Klammern [] ist nun explizit nicht mehr zulässig, da diese in der aktuellen Implementierung als Trennzeichen verwendet werden.

  Referenzen: #6216

mypy

• [mypy] [bug]

  Problem im Mypy-Plugin behoben, bei dem das Plugin den korrekten Typ für Spalten von Unterklassen nicht ableitete, die nicht direkt von TypeEngine abgeleitet waren, insbesondere von TypeDecorator und UserDefinedType.

tests

• [tests] [change]

  Ein neues Flag namens supports_schemas wurde zu DefaultDialect hinzugefügt; Drittanbieter-Dialekte können dieses Flag auf False setzen, um die Schema-bezogenen Tests von SQLAlchemy beim Ausführen der Testsuite für einen Drittanbieter-Dialekt zu deaktivieren.

1.4.6

Veröffentlicht: 6. April 2021

orm

• [orm] [bug] [regression]

  Behobene Regression, bei der eine veraltete Form von Query.join(), bei der eine Reihe von Entitäten ohne ON-Klausel in einem einzigen Query.join()-Aufruf übergeben wurde, nicht korrekt funktionierte.

  Referenzen: #6203

• [orm] [bug] [regression]

  Kritische Regression behoben, bei der die Methode Query.yield_per() im ORM das interne Result so einrichtete, dass es Blöcke auf einmal liefert, aber die neue Methode Result.unique() verwendete, die über das gesamte Ergebnis vereinheitlicht. Dies führte zu verlorenen Zeilen, da der ORM id(obj) als Vereinheitlichungsfunktion verwendet, was zu wiederholten Identifikatoren für neue Objekte führt, wenn bereits gesehene Objekte garbage collected werden. Das Verhalten in 1.3 war hier, über jeden Block zu "vereinheitlichen", was bei der Lieferung von Ergebnissen in Blöcken keine "vereinheitlichten" Ergebnisse liefert. Da die Methode Query.yield_per() bereits explizit verboten ist, wenn Joined Eager Loading aktiv ist, was der primäre Grund für die "Vereinheitlichungs"-Funktion ist, ist die "Vereinheitlichungs"-Funktion nun vollständig deaktiviert, wenn Query.yield_per() verwendet wird.

  Diese Regression betrifft nur das Legacy-Objekt Query; bei Verwendung der 2.0-Style-Ausführung wird "Vereinheitlichung" nicht automatisch angewendet. Um das Problem bei expliziter Verwendung von Result.unique() zu vermeiden, wird nun ein Fehler ausgelöst, wenn Zeilen aus einem "vereinheitlichten" ORM-Level Result abgerufen werden und gleichzeitig eine yield per API verwendet wird, da der Zweck von yield_per darin besteht, beliebig große Mengen von Zeilen zu ermöglichen, die nicht im Speicher vereinheitlicht werden können, ohne die Anzahl der Einträge zu erhöhen, um die vollständige Ergebnisgröße zu erreichen.

  Referenzen: #6206

sql

• [sql] [bug] [mssql] [oracle] [regression]

  Weitere Regressionen im selben Bereich wie bei #6173 (in 1.4.5 veröffentlicht) behoben, bei denen ein "Post-Compile"-Parameter, typischerweise jene, die für die LIMIT/OFFSET-Ausgabe in Oracle und SQL Server verwendet werden, nicht korrekt verarbeitet werden konnte, wenn derselbe Parameter an mehreren Stellen in der Anweisung gerendert wurde.

  Referenzen: #6202

• [sql] [bug]

  Die Ausführung eines Subquery mit Connection.execute() ist veraltet und wird eine Warnung ausgeben. Dieser Anwendungsfall war ein Versehen, das bereits in Version 1.4 hätte entfernt werden sollen. Die Operation führt nun aus Kompatibilitätsgründen direkt das zugrunde liegende Select-Objekt aus. Ebenso ist die Klasse CTE nicht für die Ausführung geeignet. In Version 1.3 führte der Versuch, eine CTE auszuführen, zu einer ungültigen "leeren" SQL-Anweisung. Da dieser Anwendungsfall nicht funktionierte, wird nun eine ObjectNotExecutableError ausgelöst. Zuvor versuchte Version 1.4, die CTE als Anweisung auszuführen, dies funktionierte jedoch nur unregelmäßig.

  Referenzen: #6204

schema

• [schema] [bug]

  Das Table-Objekt löst nun eine informative Fehlermeldung aus, wenn es instanziiert wird, ohne mindestens die Argumente Table.name und Table.metadata positionell zu übergeben. Zuvor, wenn diese als Schlüsselwortargumente übergeben wurden, schlug die Initialisierung des Objekts lautlos fehl.

  Diese Änderung wird auch **zurückportiert** auf: 1.3.25

  Referenzen: #6135

mypy

• [mypy] [bug]

  Eine Reihe von Refactorings und Korrekturen wurden angewendet, um den "inkrementellen" Modus von Mypy über mehrere Dateien hinweg zu unterstützen, der zuvor nicht berücksichtigt wurde. In diesem Modus muss das Mypy-Plugin Python-Datentypen, die in anderen Dateien ausgedrückt werden, mit weniger Informationen verarbeiten, als sie bei einer direkten Ausführung haben.

  Zusätzlich wurde ein neuer Dekorator declarative_mixin() hinzugefügt, der für das Mypy-Plugin notwendig ist, um eine Deklarationsmixinklasse eindeutig identifizieren zu können, die ansonsten nicht in einer bestimmten Python-Datei verwendet wird.

  Siehe auch

  Verwendung von @declared_attr und Deklarationsmixins

  Referenzen: #6147

• [mypy] [bug]

  Problem behoben, bei dem das Mypy-Plugin die "collection_class" einer Beziehung nicht interpretieren konnte, wenn es sich um einen Callable und nicht um eine Klasse handelte. Außerdem wurden die Typübereinstimmung und Fehlerberichterstattung für sammlungsorientierte Beziehungen verbessert.

  Referenzen: #6205

asyncio

• [asyncio] [usecase] [postgresql]

  Zugriffsmethoden .sqlstate und Synonym .pgcode wurden dem Attribut .orig der SQLAlchemy-Ausnahmeklasse hinzugefügt, die vom asyncpg DBAPI-Adapter ausgelöst wird, d.h. dem zwischengeschalteten Ausnahmeobjekt, das über dem von der asyncpg-Bibliothek selbst ausgelösten Objekt liegt, aber unterhalb der Ebene des SQLAlchemy-Dialekts.

  Referenzen: #6199

1.4.5

Veröffentlicht: 2. April 2021

orm

• [orm] [bug] [regression]

  Regression behoben, bei der die Laderstrategie joinedload() nicht erfolgreich zu einem Mapper verbunden war, der auf eine CTE-Struktur abgebildet war.

  Referenzen: #6172

• [orm] [bug] [regression]

  Die in #5171 hinzugefügte Warnmeldung wurde zurückgenommen, um nicht vor überlappenden Spalten in einem Vererbungsszenario zu warnen, bei dem eine bestimmte Beziehung lokal zu einer Unterklasse ist und daher keine Überlappung darstellt.

  Referenzen: #6171

sql

• [sql] [bug] [postgresql]

  Fehler in der neuen Funktion FunctionElement.render_derived() behoben, bei der Spaltennamen, die explizit in der Alias-SQL gerendert wurden, keine korrekte Anführungszeichen für Groß-/Kleinschreibung und andere nicht-alphanumerische Namen erhielten.

  Referenzen: #6183

• [sql] [bug] [regression]

  Regression behoben, bei der die Verwendung der Methode Operators.in_() mit einem Select-Objekt gegen eine nicht tabellengebundene Spalte eine AttributeError erzeugte, oder allgemeiner, die Verwendung einer ScalarSelect ohne Datentyp in einem Binärausdruck zu einem ungültigen Zustand führte.

  Referenzen: #6181

• [sql] [bug]

  Ein neues Flag wurde der Klasse Dialect namens Dialect.supports_statement_cache hinzugefügt. Dieses Flag muss nun direkt auf einer Dialektklasse vorhanden sein, damit der Query-Cache von SQLAlchemy für diesen Dialekt wirksam wird. Die Begründung basiert auf entdeckten Problemen wie #6173, die zeigen, dass Dialekte, die Literalwerte aus der kompilierten Anweisung hartkodieren, oft die numerischen Parameter für LIMIT/OFFSET, mit Caching nicht kompatibel sind, bis diese Dialekte überarbeitet werden, um nur die in der Anweisung vorhandenen Parameter zu verwenden. Für Drittanbieter-Dialekte, bei denen dieses Flag nicht gesetzt ist, wird die SQL-Protokollierung die Meldung "dialect does not support caching" anzeigen, was darauf hinweist, dass der Dialekt dieses Flag setzen sollte, sobald überprüft wurde, dass während der Kompilierungsphase keine zeileninternen Literalwerte gerendert werden.

  Siehe auch

  Caching für Drittanbieter-Dialekte

  Referenzen: #6184

schema

• [schema] [bug]

  Ein neuer Parameter Enum.omit_aliases wurde im Enum-Typ eingeführt, um das Filtern von Aliassen bei Verwendung eines PEP435-Enums zu ermöglichen. Frühere Versionen von SQLAlchemy behielten Aliase in allen Fällen bei und erstellten Datenbank-Enum-Typen mit zusätzlichen Zuständen, was bedeutet, dass sie als unterschiedliche Werte in der Datenbank behandelt wurden. Aus Kompatibilitätsgründen ist dieses Flag in der 1.4-Serie standardmäßig auf False gesetzt, wird aber in einer zukünftigen Version auf True geändert. Eine Verwarnung wird ausgegeben, wenn dieses Flag nicht angegeben wird und das übergebene Enum Aliase enthält.

  Referenzen: #6146

mypy

• [mypy] [bug]

  Problem im Mypy-Plugin behoben, bei dem die neu hinzugefügte Unterstützung für as_declarative() die DeclarativeMeta-Klasse nicht vollständig zum Zustand des Mypy-Interpreters hinzufügen musste, damit kein "Name not found"-Fehler auftritt. Außerdem wird verbessert, wie globale Namen für das Plugin eingerichtet werden, einschließlich des Namens Mapped.

  Referenzen: #sqlalchemy/sqlalchemy2-stubs/#14

asyncio

• [asyncio] [bug]

  Problem behoben, bei dem die asyncio-Erweiterung nicht geladen werden konnte, wenn Python 3.6 mit der Backport-Bibliothek für contextvars installiert war.

  Referenzen: #6166

postgresql

• [postgresql] [bug] [regression]

  Regression behoben, die durch #6023 verursacht wurde, bei der der PostgreSQL-Cast-Operator, der auf Elemente innerhalb eines ARRAY angewendet wurde, bei Verwendung von psycopg2 den korrekten Typ nicht verwenden konnte, falls der Datentyp auch innerhalb einer Instanz des Variant-Adapters eingebettet war.

  Zusätzlich wird die Unterstützung für den korrekten CREATE TYPE korrigiert, wenn ein Variant(ARRAY(some_schema_type)) verwendet wird.

  Diese Änderung wird auch **zurückportiert** auf: 1.3.25

  Referenzen: #6182

• [postgresql] [bug]

  Tippfehler in der Korrektur für #6099, veröffentlicht in 1.4.4, behoben, der diese Änderung vollständig an der korrekten Funktionsweise hinderte, d.h. die Fehlermeldung passte nicht zu dem, was tatsächlich von pg8000 ausgegeben wurde.

  Referenzen: #6099

• [postgresql] [bug]

  Problem behoben, bei dem der PostgreSQL PGInspector bei Generierung gegen eine Engine für .get_enums(), .get_view_names(), .get_foreign_table_names() und .get_table_oid() bei Verwendung gegen eine "future"-Style Engine und nicht direkt gegen die Verbindung fehlschlug.

  Referenzen: #6170

mysql

• [mysql] [bug] [regression]

  Regression im MySQL-Dialekt behoben, bei der die Reflexionsabfrage zur Erkennung, ob eine Tabelle existiert, bei sehr alten MySQL 5.0- und 5.1-Versionen fehlschlug.

  Referenzen: #6163

mssql

• [mssql] [bug]

  Regression in MSSQL 2012+ behoben, die verhinderte, dass die ORDER BY-Klausel gerendert wurde, wenn offset=0 in einer Unterabfrage verwendet wurde.

  Referenzen: #6163

oracle

• [oracle] [bug] [regression]

  Kritische Regression behoben, bei der der Oracle-Compiler die korrekten Parameterwerte für LIMIT/OFFSET bei einer Select-Anweisung aufgrund eines Caching-Problems nicht beibehielt.

  Referenzen: #6173

1.4.4

Veröffentlicht: 30. März 2021

orm

• [orm] [bug]

  Kritische Probleme in der neuen Funktion PropComparator.and_() behoben, bei der Laderstrategien, die sekundäre SELECT-Anweisungen ausgeben, wie selectinload() und lazyload(), gebundene Parameter in den benutzerdefinierten Kriterien nicht korrekt für die aktuell ausgeführte Anweisung (im Gegensatz zur gecachten Anweisung) berücksichtigten, was zu veralteten gebundenen Werten führte.

  Dies fügt auch eine Warnung für den Fall hinzu, dass versucht wird, ein Objekt, das lazyload() in Verbindung mit PropComparator.and_() verwendet, zu serialisieren. Die Ladekriterien können nicht zuverlässig serialisiert und deserialisiert werden, und für diesen Fall sollte Eager Loading verwendet werden.

  Referenzen: #6139

• [orm] [bug] [regression]

  Fehlende Methode Session.get() aus dem ScopedSession-Interface wiederhergestellt.

  Referenzen: #6144

engine

• [engine] [usecase]

  Der Kontextmanager, der von Transaction verwendet wird, wurde modifiziert, so dass keine Warnung "bereits getrennt" beim Beenden des Kontextmanagers ausgegeben wird, wenn die Transaktion bereits manuell innerhalb des Blocks zurückgesetzt wurde. Dies gilt für reguläre Transaktionen, Savepoint-Transaktionen und Legacy-Marker-Transaktionen. Eine Warnung wird weiterhin ausgegeben, wenn die Methode .rollback() explizit mehr als einmal aufgerufen wird.

  Referenzen: #6155

• [engine] [bug]

  Falsche Argumente an die Ausnahmebehandlungsmethode in CursorResult repariert.

  Referenzen: #6138

postgresql

• [postgresql] [bug] [reflection]

  Problem bei der PostgreSQL-Reflexion behoben, bei dem eine Spalte, die "NOT NULL" ausdrückt, die Nullbarkeit eines entsprechenden Domänentyps überschrieb.

  Diese Änderung wird auch **zurückportiert** nach: 1.3.24

  Referenzen: #6161

• [postgresql] [bug]

  Der is_disconnect()-Handler für den pg8000-Dialekt wurde modifiziert, der nun eine neue InterfaceError von pg8000 1.19.0 berücksichtigt. Pull Request von Hamdi Burak Usul.

  Referenzen: #6099

misc

• [misc] [bug]

  Die Verwendung der Bibliothek importlib_metadata zum Laden von Setuptools-Eintrittspunkten wurde angepasst, um einigen Deprecationsänderungen Rechnung zu tragen.

1.4.3

Veröffentlicht: 25. März 2021

orm

• [orm] [bug]

  Fehler behoben, bei dem Python 2.7.5 (Standard unter CentOS 7) SQLAlchemy nicht importieren konnte, da auf dieser Python-Version exec "statement" und exec("statement") nicht dasselbe Verhalten zeigten. Die Kompatibilitätsfunktion exec_() wurde stattdessen verwendet.

  Referenzen: #6069

• [orm] [bug]

  Fehler behoben, bei dem ORM-Abfragen, die eine korrelierte Unterabfrage in Verbindung mit column_property() verwendeten, nicht korrekt mit einer umschließenden Unterabfrage oder einer CTE korrelierten, wenn Select.correlate_except() in der Eigenschaft zur Steuerung der Korrelation verwendet wurde. Dies geschah in Fällen, in denen die Unterabfrage dieselben Selektierbaren enthielt wie diejenigen innerhalb der korrelierten Unterabfrage, die nicht korreliert werden sollten.

  Referenzen: #6060

• [orm] [bug]

  Fehler behoben, bei dem Kombinationen der neuen Funktion "Beziehung mit Kriterien" mit Funktionen, die die neue Funktion "Lambda SQL" verwenden, wie z.B. Laderstrategien wie selectinload und lazyload, in komplizierteren Szenarien wie polymorphem Laden fehlschlugen.

  Referenzen: #6131

• [orm] [bug]

  Unterstützung wiederhergestellt, so dass die Methode ClauseElement.params() korrekt mit einem Select-Objekt arbeiten kann, das Joins über ORM-Beziehungsstrukturen enthält, was eine neue Funktion in 1.4 ist.

  Referenzen: #6124

• [orm] [bug]

  Problem behoben, bei dem eine "in 2.0 entfernte" Warnung intern durch die Mechanik des Beziehungsladers generiert wurde.

  Referenzen: #6115

orm declarative

• [orm] [declarative] [bug] [regression]

  Regression behoben, bei der das Attribut .metadata auf Klassenebene nicht beachtet wurde, was den Anwendungsfall der MetaData pro Klassenhierarchie für abstrakte deklarative Klassen und Mixins unterbrach.

  Siehe auch

  metadata

  Referenzen: #6128

engine

• [engine] [bug] [regression]

  Der Name ResultProxy wurde zurück in den Namespace sqlalchemy.engine verschoben. Dieser Name bezieht sich auf das Objekt LegacyCursorResult.

  Referenzen: #6119

schema

• [schema] [bug]

  Die Logik, die DROP-Anweisungen für Sequence-Objekte beim Löschen mehrerer Tabellen ausgibt, wurde angepasst, so dass alle Sequence-Objekte nach allen Tabellen gelöscht werden, auch wenn die gegebene Sequence nur mit einem Table-Objekt und nicht direkt mit dem gesamten MetaData-Objekt verknüpft ist. Der Anwendungsfall unterstützt, dass dieselbe Sequence gleichzeitig mit mehr als einer Table assoziiert ist.

  Diese Änderung wird auch **zurückportiert** nach: 1.3.24

  Referenzen: #6071

mypy

• [mypy] [bug]

  Unterstützung für die Mypy-Erweiterung hinzugefügt, um eine deklarative Basisklasse, die mit der Funktion as_declarative() sowie der Methode registry.as_declarative_base() generiert wird, korrekt zu interpretieren.

• [mypy] [bug]

  Fehler im Mypy-Plugin behoben, bei dem die Python-Typenerkennung für den Spaltentyp Boolean eine Ausnahme auslöste; zusätzlich wurde die Unterstützung für Enum implementiert, einschließlich der Erkennung eines stringbasierten Enums im Vergleich zur Verwendung von Python enum.Enum.

  Referenzen: #6109

postgresql

• [postgresql] [bug] [types]

  Der psycopg2-Dialekt wurde angepasst, um einen expliziten PostgreSQL-Cast für gebundene Parameter mit ARRAY-Elementen auszugeben. Dies ermöglicht die korrekte Funktion des gesamten Datentypspektrums innerhalb von Arrays. Der asyncpg-Dialekt generierte diese internen Casts bereits in der endgültigen Anweisung. Dies beinhaltet auch die Unterstützung für Array-Slice-Updates sowie die PostgreSQL-spezifische Methode ARRAY.contains().

  Diese Änderung wird auch **zurückportiert** nach: 1.3.24

  Referenzen: #6023

• [postgresql] [bug] [reflection]

  Reflexion von Identitätsspalten in Tabellen mit gemischt groß- und kleingeschriebenen Namen in PostgreSQL behoben.

  Referenzen: #6129

sqlite

• [sqlite] [feature] [asyncio]

  Unterstützung für den aiosqlite-Datenbanktreiber für die Verwendung mit der SQLAlchemy asyncio-Erweiterung hinzugefügt.

  Siehe auch

  Aiosqlite

  Referenzen: #5920

• [sqlite] [bug] [regression]

  Der pysqlcipher-Dialekt zur korrekten Verbindung wurde repariert, der in Version 1.4 eine Regression erlitten hatte. Test und CI-Unterstützung wurden hinzugefügt, um den Treiber funktionsfähig zu halten. Der Dialekt importiert nun standardmäßig das Modul sqlcipher3 für Python 3, bevor er auf pysqlcipher3 zurückgreift, das als nicht mehr gepflegt dokumentiert ist.

  Siehe auch

  Pysqlcipher

  Referenzen: #5848

1.4.2

Veröffentlicht: 19. März 2021

orm

• [orm] [usecase] [dataclasses]

  Unterstützung für das Objekt declared_attr im Kontext von Dataclass-Feldern hinzugefügt.

  Siehe auch

  Verwendung von Deklarativen Mixins mit vorbestehenden Dataclasses

  Referenzen: #6100

• [orm] [bug] [dataclasses]

  Problem in neuer ORM-Dataclass-Funktionalität behoben, bei dem Dataclass-Felder in einer abstrakten Basisklasse oder einem Mixin, die Spalten- oder andere Mapping-Konstrukte enthielten, nicht gemappt wurden, wenn sie auch einen „default“-Schlüssel innerhalb von dataclasses.field() enthielten.

  Referenzen: #6093

• [orm] [bug] [regression]

  Regression behoben, bei der der Query.selectable-Accessor, der ein Synonym für Query.__clause_element__() ist, entfernt wurde. Er wurde nun wiederhergestellt.

  Referenzen: #6088

• [orm] [bug] [regression]

  Regression behoben, bei der die Verwendung eines unbenannten SQL-Ausdrucks wie einer SQL-Funktion einen Fehler bei der Spaltenzielsetzung auslöste, wenn die Abfrage selbst joinedload für eine Entität verwendete und durch den joinedload-Eager-Loading-Prozess in eine Subabfrage eingebettet wurde.

  Referenzen: #6086

• [orm] [bug] [regression]

  Regression behoben, bei der die Methode Query.filter_by() die richtige Quellentität nicht finden konnte, wenn die Methode Query.join() verwendet wurde, um auf eine Entität ohne ON-Klausel zu zielen.

  Referenzen: #6092

• [orm] [bug] [regression]

  Regression behoben, bei der die SQL-Kompilierung einer Function nicht korrekt funktionierte, wenn das Objekt „annotiert“ war, ein interner Memoization-Prozess, der hauptsächlich vom ORM verwendet wird. Dies konnte insbesondere ORM-Lazy-Loads beeinträchtigen, die diese Funktion in 1.4 stärker nutzen.

  Referenzen: #6095

• [orm] [bug]

  Regression behoben, bei der ConcreteBase überhaupt nicht mappte, wenn ein gemappter Spaltenname mit dem Diskriminatorspaltennamen überlappte, was zu einem AssertionError führte. Der Anwendungsfall funktionierte in 1.3 nicht korrekt, da die polymorphe Vereinigung eine Abfrage erzeugte, die die Diskriminatorspalte vollständig ignorierte und gleichzeitig Warnungen vor doppelten Spalten ausgab. Da die Architektur von 1.4 das bisherige fehlerhafte Verhalten von 1.3 auf der select()-Ebene derzeit nicht leicht reproduzieren kann, löst der Anwendungsfall nun eine informative Fehlermeldung aus, die den Benutzer auffordert, das Attribut .ConcreteBase._concrete_discriminator_name zur Behebung des Konflikts zu verwenden. Um diese Konfiguration zu unterstützen, kann .ConcreteBase._concrete_discriminator_name nur auf der Basisklasse platziert werden, wo es automatisch von Unterklassen verwendet wird; zuvor war dies nicht der Fall.

  Referenzen: #6090

engine

• [engine] [bug] [regression]

  Oberster Import für sqlalchemy.engine.reflection wiederhergestellt. Dies stellt sicher, dass die Basisklasse Inspector korrekt registriert ist, damit inspect() für Dialekte von Drittanbietern funktioniert, die dieses Paket sonst nicht importieren.

sql

• [sql] [bug] [regression]

  Problem behoben, bei dem die Verwendung einer func, die punktierte Paketnamen enthält, nicht von der SQL-Caching-System gecached werden konnte, da eine Python-Liste von Namen ein Tupel sein musste.

  Referenzen: #6101

• [sql] [bug] [regression]

  Regression im case()-Konstrukt behoben, bei der die „Dictionary“-Form der Argumentenspezifikation nicht korrekt funktionierte, wenn sie positionsabhängig und nicht als Schlüsselwortargument whens übergeben wurde.

  Referenzen: #6097

mypy

• [mypy] [bug]

  Problem in der MyPy-Erweiterung behoben, die beim Erkennen des Typs einer Column abstürzte, wenn der Typ mit einem Modulpräfix wie sa.Integer() angegeben wurde.

  Referenzen: #sqlalchemy/sqlalchemy2-stubs/2

postgresql

• [postgresql] [usecase]

  Umbenennung des Spaltennamens, der von einer Reflektionsabfrage verwendet wird, die ein reserviertes Wort in einigen PostgreSQL-kompatiblen Datenbanken verwendete.

  Referenzen: #6982

1.4.1

Veröffentlicht: 17. März 2021

orm

• [orm] [bug] [regression]

  Regression behoben, bei der die Erzeugung eines Core-Ausdrucks wie select() mit ORM-Entitäten die Mapper eilig konfigurierte, um die Kompatibilität mit dem Objekt Query aufrechtzuerhalten, was dies zwangsläufig tut, um viele Backref-bezogene Legacy-Fälle zu unterstützen. Core select()-Konstrukte werden jedoch auch in Mapper-Konfigurationen verwendet, und in diesem Umfang ist die eilig Konfiguration eher eine Unannehmlichkeit, so dass die eilig Konfiguration für select() und andere Core-Konstrukte deaktiviert wurde, wenn keine ORM-Ladefunktionen wie Load vorhanden waren.

  Die Änderung behält das Verhalten von Query bei, um die Abwärtskompatibilität zu gewährleisten. Wenn jedoch ein select() in Verbindung mit ORM-Entitäten verwendet wird, ist eine „Backref“, die nicht explizit auf einer der Klassen bis zur Mapper-Konfigurationszeit platziert ist, nicht verfügbar, es sei denn, configure_mappers() oder das neuere configure() wurde anderswo aufgerufen. Bevorzugen Sie die Verwendung von relationship.back_populates für eine explizitere Beziehungszuordnung, die keine eilig Konfigurationsanforderung hat.

  Referenzen: #6066

• [orm] [bug] [regression]

  Kritische Regression im Relationship Lazy Loader behoben, bei der die SQL-Kriterien zum Abrufen eines zugehörigen Many-to-One-Objekts im Verhältnis zu anderen memoisierten Strukturen im Loader veraltet sein konnten, wenn der Mapper Konfigurationsänderungen aufwies, wie sie bei spät oder nach Bedarf konfigurierten Mappern auftreten können, was zu einem Vergleich mit None führte und kein Objekt zurückgab. Vielen Dank an Alan Hamlett für seine Hilfe bei der Nachverfolgung bis spät in die Nacht.

  Referenzen: #6055

• [orm] [bug] [regression]

  Regression behoben, bei der die Methode Query.exists() keinen Ausdruck erstellen konnte, wenn die Entitätsliste der Query ein beliebiger SQL-Spaltenausdruck war.

  Referenzen: #6076

• [orm] [bug] [regression]

  Regression behoben, bei der der Aufruf von Query.count() in Verbindung mit einer Ladeoption wie joinedload() die Ladeoption nicht ignorierte. Dies ist ein Verhalten, das schon immer sehr spezifisch für die Methode Query.count() war; normalerweise wird ein Fehler ausgelöst, wenn eine gegebene Query Optionen hat, die nicht für das gelten, was sie zurückgibt.

  Referenzen: #6052

• [orm] [bug] [regression]

  Regression in Session.identity_key() behoben, einschließlich der Tatsache, dass die Methode und verwandte Methoden nicht durch Unit-Tests abgedeckt waren und dass die Methode einen Tippfehler enthielt, der ihre korrekte Funktion verhinderte.

  Referenzen: #6067

orm declarative

• [orm] [declarative] [bug] [regression]

  Fehler behoben, bei dem benutzerdefinierte Klassen, die ein Attribut namens „registry“ enthielten, Konflikte mit dem neuen registry-basierten Mapping-System bei Verwendung von DeclarativeMeta verursachten. Während das Attribut weiterhin explizit auf einer deklarativen Basis gesetzt werden kann, um von der Metaklasse verarbeitet zu werden, wird es nach dem Auffinden unter einer privaten Klassenvariable abgelegt, damit es nicht mit zukünftigen Unterklassen, die denselben Namen für andere Zwecke verwenden, in Konflikt gerät.

  Referenzen: #6054

engine

• [engine] [bug] [regression]

  Das Python namedtuple() hat das Verhalten, dass die Namen count und index als Tupelwerte bereitgestellt werden, wenn das benannte Tupel diese Namen enthält; wenn sie fehlen, wird ihr Verhalten als Methoden von collections.abc.Sequence beibehalten. Daher wurden die Klassen Row und LegacyRow korrigiert, damit sie sich auf die gleiche Weise verhalten und das erwartete Verhalten für Datenbankzeilen mit Spalten namens „index“ oder „count“ beibehalten.

  Referenzen: #6074

mssql

• [mssql] [bug] [regression]

  Regression behoben, bei der eine neue setinputsizes() API, die für pyodbc verfügbar ist, aktiviert wurde, die anscheinend mit dem fast_executemany()-Modus von pyodbc nicht kompatibel ist, wenn keine genaueren Typinformationen vorhanden sind, die derzeit noch nicht vollständig implementiert oder getestet sind. Der pyodbc-Dialekt und -Connector wurde so modifiziert, dass setinputsizes() überhaupt nicht verwendet wird, es sei denn, der Parameter use_setinputsizes wird an den Dialekt übergeben, z. B. über create_engine(). Zu diesem Zeitpunkt kann sein Verhalten mithilfe des Hooks DialectEvents.do_setinputsizes() angepasst werden.

  Siehe auch

  Setinputsizes-Unterstützung

  Referenzen: #6058

misc

• [bug] [regression]

  items und values wurden der Klasse ColumnCollection wieder hinzugefügt. Die Regression wurde bei der Hinzufügung von Unterstützung für doppelte Spalten in Klauseln und wählbarer Elemente in Ticket #4753 eingeführt.

  Referenzen: #6068

1.4.0

Veröffentlicht: 15. März 2021

orm

• [orm] [bug]

  Eine sehr alte Warnung, die besagt, dass passive_deletes nicht für Many-to-One-Beziehungen vorgesehen ist, wurde entfernt. Obwohl es wahrscheinlich ist, dass in vielen Fällen das Setzen dieses Parameters auf eine Many-to-One-Beziehung nicht beabsichtigt war, gibt es Anwendungsfälle, in denen ein Löschkaskadieren, das aus einer solchen Beziehung folgt, unterbunden werden soll.

  Diese Änderung wird auch **zurückportiert** nach: 1.3.24

  Referenzen: #5983

• [orm] [bug]

  Problem behoben, bei dem der Prozess des Verbindens zweier Tabellen fehlschlagen konnte, wenn eine der Tabellen eine nicht zusammenhängende, unauflösbare Fremdschlüsselbeschränkung hatte, die im Verbindungsprozess eine NoReferenceError auslöste, die dennoch umgangen werden konnte, um die Verbindung zu ermöglichen. Die Logik, die die Ausnahme auf ihre Signifikanz im Prozess testete, traf Annahmen über das Konstrukt, die fehlschlugen.

  Diese Änderung wird auch **zurückportiert** nach: 1.3.24

  Referenzen: #5952

• [orm] [bug]

  Problem behoben, bei dem das Konstrukt MutableComposite in einen ungültigen Zustand geraten konnte, wenn das übergeordnete Objekt bereits geladen war und dann durch eine nachfolgende Abfrage abgedeckt wurde, aufgrund des Aktualisierungs-Handlers der Verbundseigenschaften, der das Objekt durch ein neues, nicht von der erweiterbaren Erweiterung behandeltes Objekt ersetzte.

  Diese Änderung wird auch **zurückportiert** nach: 1.3.24

  Referenzen: #6001

• [orm] [bug]

  Regression behoben, bei der der Parameter relationship.query_class für „dynamische“ Beziehungen nicht mehr funktionierte. Die AppenderQuery hängt weiterhin von der Legacy-Klasse Query ab; Benutzer werden ermutigt, von der Verwendung von „dynamischen“ Beziehungen auf die Verwendung von with_parent() umzusteigen.

  Referenzen: #5981

• [orm] [bug] [regression]

  Regression behoben, bei der Query.join() keine Auswirkung hatte, wenn die Abfrage selbst sowie das Join-Ziel gegen ein Objekt Table und nicht gegen eine gemappte Klasse gerichtet waren. Dies war Teil eines systemischeren Problems, bei dem der Legacy-ORM-Abfragecompiler nicht korrekt aus einer Query verwendet wurde, wenn die erzeugte Anweisung keine ORM-Entitäten enthielt.

  Referenzen: #6003

• [orm] [bug] [asyncio]

  Die API für AsyncSession.delete() ist jetzt awaitable; diese Methode kaskadiert entlang von Beziehungen, die auf ähnliche Weise geladen werden müssen wie die Methode AsyncSession.merge().

  Referenzen: #5998

• [orm] [bug]

  Der Unit-of-Work-Prozess deaktiviert nun das Verhalten „lazy='raise'“ vollständig, wenn ein Flush stattfindet. Obwohl es Bereiche gibt, in denen die UOW manchmal Dinge lädt, die letztendlich nicht benötigt werden, ist die Strategie lazy="raise" hier nicht hilfreich, da der Benutzer oft wenig Kontrolle oder Einsicht in den Flush-Prozess hat.

  Referenzen: #5984

engine

• [engine] [bug]

  Fehler behoben, bei dem das Feature „schema_translate_map“ für den Anwendungsfall der direkten Ausführung von DefaultGenerator-Objekten wie Sequenzen nicht berücksichtigt wurde, einschließlich des Falls, in dem sie „vorab ausgeführt“ wurden, um Primärschlüsselwerte zu generieren, wenn implicit_returning deaktiviert war.

  Diese Änderung wird auch **zurückportiert** nach: 1.3.24

  Referenzen: #5929

• [engine] [bug]

  Verbesserte Engine-Protokollierung, um ROLLBACK und COMMIT zu vermerken, die protokolliert werden, während sich der DBAPI-Treiber im AUTOCOMMIT-Modus befindet. Diese ROLLBACK/COMMIT sind auf Bibliotheksebene und haben keine Auswirkung, wenn AUTOCOMMIT aktiv ist. Es ist jedoch trotzdem erwähnenswert, da sie anzeigen, wo SQLAlchemy die Transaktionsabgrenzung sieht.

  Referenzen: #6002

• [engine] [bug] [regression]

  Regression behoben, bei der der „Reset-Agent“ des Connection-Pools von der Connection beim Schließen nicht wirklich genutzt wurde, was auch zu einem doppelten Rollback-Szenario führte, das etwas verschwenderisch war. Die neuere Architektur der Engine wurde aktualisiert, so dass die „Reset-on-Return“-Logik des Connection-Pools übersprungen wird, wenn die Connection die Transaktion explizit schließt, bevor der Pool an die Verbindung zurückgegeben wird.

  Referenzen: #6004

sql

• [sql] [change]

  Die Kompilierung des CTE-Konstrukts wurde geändert, so dass eine Zeichenkette zurückgegeben wird, die die innere SELECT-Anweisung darstellt, wenn die CTE direkt als Zeichenkette behandelt wird, außerhalb des Kontexts einer umschließenden SELECT. Dies ist dasselbe Verhalten wie bei FromClause.alias() und Select.subquery(). Zuvor wurde eine leere Zeichenkette zurückgegeben, da die CTE normalerweise oberhalb einer SELECT platziert wird, nachdem diese SELECT generiert wurde, was beim Debugging generell irreführend ist.

• [sql] [bug]

  Fehler behoben, bei dem die „Prozent-Escaping“-Funktion, die bei Dialekten mit den Bound-Parameter-Stilen „format“ oder „pyformat“ auftritt, für die Konstrukte Operators.op() und custom_op für benutzerdefinierte Operatoren, die Prozentzeichen verwenden, nicht aktiviert war. Das Prozentzeichen wird nun automatisch verdoppelt, basierend auf dem Paramstyle, wie erforderlich.

  Referenzen: #6016

• [sql] [bug] [regression]

  Regression behoben, bei der der Fehler „unsupported compilation error“ für unbekannte Datentypen nicht korrekt ausgelöst wurde.

  Referenzen: #5979

• [sql] [bug] [regression]

  Regression behoben, bei der die Verwendung des eigenständigen distinct() in der Form, dass es direkt SELECTed wurde, dazu führte, dass es im Ergebnisset nicht nach Spaltenidentität gefunden werden konnte, was die Art und Weise ist, wie das ORM Spalten findet. Während eigenständiges distinct() nicht darauf ausgelegt ist, direkt SELECTed zu werden (verwenden Sie select.distinct() für ein reguläres SELECT DISTINCT..), war es bisher bis zu einem gewissen Grad in dieser Form nutzbar (konnte aber z. B. nicht in Subabfragen funktionieren). Die Spaltenzielsetzung für unäre Ausdrücke wie „DISTINCT <col>“ wurde verbessert, damit dieser Fall wieder funktioniert, und eine zusätzliche Verbesserung wurde vorgenommen, so dass die Verwendung dieser Form in einer Subabfrage zumindest gültiges SQL erzeugt, was zuvor nicht der Fall war.

  Die Änderung erweitert zusätzlich die Möglichkeit, Elemente in row._mapping basierend auf SQL-Ausdrucksobjekten in ORM-aktivierten SELECT-Anweisungen anzusprechen, einschließlich der Frage, ob die Anweisung durch connection.execute() oder session.execute() aufgerufen wurde.

  Referenzen: #6008

schema

• [schema] [bug] [sqlite]

  Problem behoben, bei dem die durch Boolean oder Enum generierte CHECK-Beschränkung die Namenskonvention nach der ersten Kompilierung nicht korrekt rendern konnte, aufgrund einer unbeabsichtigten Zustandsänderung innerhalb des Namens, der der Beschränkung gegeben wurde. Dieses Problem wurde zuerst in 0.9 in der Korrektur für Issue #3067 eingeführt, und die Korrektur überarbeitet den damals gewählten Ansatz, der anscheinend aufwendiger war als nötig.

  Diese Änderung wird auch **zurückportiert** nach: 1.3.24

  Referenzen: #6007

• [schema] [bug]

  Unterstützung für Namenskonventionen von Primärschlüsselbeschränkungen, die Spaltennamen/Schlüssel usw. als Teil der Konvention verwenden, wurde repariert/implementiert. Dies beinhaltet insbesondere, dass das Objekt PrimaryKeyConstraint, das automatisch einer Table zugeordnet ist, seinen Namen aktualisiert, wenn neue Primärschlüssel-Objekte Column zur Tabelle und dann zur Beschränkung hinzugefügt werden. Interne Fehler im Zusammenhang mit diesem Beschränkungserstellungsprozess, einschließlich des Fehlens von Spalten, des Fehlens eines Namens oder eines leeren Namens, werden nun berücksichtigt.

  Diese Änderung wird auch **zurückportiert** nach: 1.3.24

  Referenzen: #5919

• [schema] [bug]

  Alle Schema-Level-Methoden .copy() wurden als veraltet markiert und in _copy() umbenannt. Dies sind keine Standard-Python-„copy()“-Methoden, da sie typischerweise darauf angewiesen sind, in bestimmten Kontexten instanziiert zu werden, die der Methode als optionale Schlüsselwortargumente übergeben werden. Die Methode Table.tometadata() ist die öffentliche API, die das Kopieren von Table-Objekten bereitstellt.

  Referenzen: #5953

mypy

• [mypy] [feature]

  Rudimentäre und experimentelle Unterstützung für Mypy wurde in Form eines neuen Plugins hinzugefügt, das selbst von neuen Typ-Stubs für SQLAlchemy abhängt. Das Plugin ermöglicht es deklarativen Mappings in ihrer Standardform, sowohl mit Mypy kompatibel zu sein als auch Typunterstützung für gemappte Klassen und Instanzen bereitzustellen.

  Siehe auch

  Mypy / Pep-484 Unterstützung für ORM-Mappings

  Referenzen: #4609

postgresql

• [postgresql] [usecase] [asyncio] [mysql]

  Ein asyncio.Lock() wurde innerhalb des emulierten DBAPI-Cursors von SQLAlchemy, lokal für die Verbindung, für die asyncpg- und aiomysql-Dialekte für den Geltungsbereich der Methoden cursor.execute() und cursor.executemany() hinzugefügt. Die Begründung ist, Fehler und Beschädigungen für den Fall zu verhindern, dass die Verbindung in mehreren Awaitables gleichzeitig verwendet wird.

  Während dieser Anwendungsfall auch mit Thread-Code und nicht-asyncio-Dialekten auftreten kann, erwarten wir, dass diese Art von Nutzung unter asyncio häufiger vorkommt, da die asyncio-API eine solche Nutzung fördert. Es ist definitiv besser, eine eigene Verbindung pro gleichzeitiger Awaitable zu verwenden, da sonst keine Gleichzeitigkeit erreicht wird.

  Für den asyncpg-Dialekt verhindert dies, dass der Zeitraum zwischen dem Aufruf von prepare() und fetch() gleichzeitige Ausführungen auf der Verbindung zulässt und Schnittstellenfehler-Ausnahmen auslöst, und verhindert auch Race Conditions beim Starten einer neuen Transaktion. Andere PostgreSQL DBAPIs sind auf Verbindungsebene threadsicher, daher zielt dies darauf ab, ein ähnliches Verhalten außerhalb des Bereichs von serverseitigen Cursorn bereitzustellen.

  Für den aiomysql-Dialekt bietet das Mutex Sicherheit, damit die Anweisungsausführung und der Abruf des Ergebnissatzes, die zwei getrennte Schritte auf Verbindungsebene sind, nicht durch gleichzeitige Ausführungen auf derselben Verbindung beschädigt werden.

  Referenzen: #5967

• [postgresql] [bug]

  Behebt ein Problem, bei dem die Verwendung von aggregate_order_by unter bestimmten Bedingungen ARRAY(NullType) zurückgab, was die Fähigkeit des Ergebnisobjekts beeinträchtigte, Daten korrekt zurückzugeben.

  Diese Änderung wird auch **zurückportiert** nach: 1.3.24

  Referenzen: #5989

mssql

• [mssql] [bug]

  Behebt einen Refactoring-Fehler für MSSQL 2005, der durch die Refaktorierung gefilterter Indizes eingeführt wurde.

  Referenzen: #5919

misc

• [usecase] [ext]

  Fügt den neuen Parameter AutomapBase.prepare.reflection_options hinzu, um die Übergabe von MetaData.reflect()-Optionen wie only oder dialektspezifischen Reflektionsoptionen wie oracle_resolve_synonyms zu ermöglichen.

  Referenzen: #5942

• [bug] [ext]

  Die Erweiterung sqlalchemy.ext.mutable verfolgt nun die "Eltern"-Sammlung unter Verwendung des InstanceState, der den Objekten zugeordnet ist, anstelle des Objekts selbst. Der letztere Ansatz erforderte, dass das Objekt hashbar ist, damit es sich in einem WeakKeyDictionary befinden kann, was gegen den Verhaltenskontrakt des ORM im Allgemeinen verstößt, nämlich dass ORM-gemappte Objekte keine besondere Art von __hash__()-Methode bereitstellen müssen und dass nicht hashbare Objekte unterstützt werden.

  Referenzen: #6020

1.4.0b3

Veröffentlicht: 15. Februar 2021

orm

• [orm] [feature]

  Das ORM, das im 2.0-Stil verwendet wird, kann nun ORM-Objekte aus den Zeilen zurückgeben, die von einer UPDATE..RETURNING- oder INSERT..RETURNING-Anweisung zurückgegeben werden, indem die Konstruktion Select.from_statement() in einem ORM-Kontext bereitgestellt wird.

  Siehe auch

  Verwenden von INSERT, UPDATE und ON CONFLICT (d. h. Upsert) zur Rückgabe von ORM-Objekten

• [orm] [bug]

  Behebt ein Problem in den neuen ORM-Abfragen im Stil 1.4/2.0, bei dem ein auf Anweisungsebene basierender Labelstil nicht in den Schlüsseln der Ergebniszeilen beibehalten wurde; dies wurde auf alle Kombinationen von Core/ORM-Spalten / Session vs. Connection usw. angewendet, sodass die Verknüpfung von Anweisung zu Ergebniszeile in allen Fällen gleich ist. Als Teil dieser Änderung wurde die Benennung von Spaltenausdrücken in Zeilen verbessert, um den ursprünglichen Namen des ORM-Attributs beizubehalten, auch wenn er in einer Unterabfrage verwendet wurde.

  Referenzen: #5933

engine

• [engine] [bug] [postgresql]

  Fortsetzung der Verbesserung, die als Teil von #5653 vorgenommen wurde, zur weiteren Unterstützung von gebundenen Parameternamen, einschließlich derjenigen, die gegen Spaltennamen generiert werden, für Namen, die Doppelpunkte, Klammern und Fragezeichen enthalten, sowie verbesserte Testunterstützung, sodass gebundene Parameternamen, auch wenn sie automatisch aus Spaltennamen abgeleitet werden, keine Probleme mit Klammern im "pyformat"-Stil von psycopg2 haben sollten.

  Als Teil dieser Änderung wurde das Format, das vom asyncpg DBAPI-Adapter (der lokal zum asyncpg-Dialekt von SQLAlchemy ist) verwendet wird, von der Verwendung des "qmark"-Parametierstils auf "format" geändert, da es einen Standard und intern unterstützten SQL-Zeichenketten-Escaping-Stil für Namen gibt, die Prozentzeichen mit dem "format"-Stil verwenden (d. h. doppelte Prozentzeichen), im Gegensatz zu Namen, die Fragezeichen mit dem "qmark"-Stil verwenden (wo kein Escaping-System durch pep-249 oder Python definiert ist).

  Siehe auch

  Der psycopg2-Dialekt hat keine Einschränkungen mehr bezüglich der gebundenen Parameternamen

  Referenzen: #5941

sql

• [sql] [usecase] [postgresql] [sqlite]

  Erweiterung des Schlüsselworts set_ von OnConflictDoUpdate, um eine ColumnCollection zu akzeptieren, wie z. B. die .c.-Sammlung eines Selectable oder das kontextuelle Objekt .excluded.

  Referenzen: #5939

• [sql] [bug]

  Behebt einen Fehler, bei dem die Assertion für das "kartesische Produkt" nicht korrekt für Joins zwischen Tabellen, die LATERAL zur Verbindung von einer Unterabfrage zu einer anderen Unterabfrage im umschließenden Kontext nutzten, berücksichtigt wurde.

  Referenzen: #5924

• [sql] [bug]

  Behebt eine Regression in Version 1.4, bei der die Methode Function.in_() nicht durch Tests abgedeckt war und in allen Fällen nicht ordnungsgemäß funktionierte.

  Referenzen: #5934

• [sql] [bug]

  Behebt eine Regression, bei der die Verwendung eines beliebigen Iterables mit der Funktion select() außerhalb von einfachen Listen nicht funktionierte. Die Vorwärts-/Rückwärtskompatibilitätslogik prüft nun auf eine breitere Palette eingehender "Iterable"-Typen, einschließlich der direkten Übergabe einer .c-Sammlung aus einem Wählbaren. Pull-Request von Oliver Rice.

  Referenzen: #5935

1.4.0b2

Veröffentlicht: 3. Februar 2021

general

• [general] [bug]

  Behebt eine SQLite-Quelldatei, die Nicht-ASCII-Zeichen in ihrem Docstring ohne Quellkodierung enthielt, eingeführt durch das Feature "INSERT..ON CONFLICT", was unter Python 2 zu Fehlern führte.

platform

• [platform] [performance]

  Einige Elemente im Zusammenhang mit der internen Klassenerzeugung beim Import wurden angepasst, was die Importzeit der Bibliothek im Vergleich zu Version 1.3 erheblich verzögerte. Die Zeit ist nun etwa 20-30 % langsamer als 1.3 statt 200 %.

  Referenzen: #5681

orm

• [orm] [usecase]

  Fügt ORMExecuteState.bind_mapper und ORMExecuteState.all_mappers Zugriffe zum Ereignisobjekt ORMExecuteState hinzu, sodass Handler auf den Zielmapper und/oder die zugeordnete Klasse oder Klassen reagieren können, die an einer ORM-Anweisungsausführung beteiligt sind.

• [orm] [usecase] [asyncio]

  Fügt AsyncSession.scalar(), AsyncSession.get() sowie Unterstützung für sessionmaker.begin() hinzu, damit diese als asynchroner Kontextmanager mit AsyncSession funktionieren. Fügt auch den AsyncSession.in_transaction()-Accessor hinzu.

  Referenzen: #5796, #5797, #5802

• [orm] [changed]

  Die Mapper-Konfiguration, die innerhalb der Funktion configure_mappers() stattfindet, ist nun pro Registrierung organisiert. Dies ermöglicht es beispielsweise, die Mapper innerhalb einer bestimmten deklarativen Basis zu konfigurieren, nicht aber die einer anderen Basis, die ebenfalls im Speicher vorhanden ist. Ziel ist es, die Anwendungsstartzeit zu verkürzen, indem der "Konfigurationsprozess" nur für benötigte Mapper-Sätze ausgeführt wird. Dies fügt auch die Methode registry.configure() hinzu, die die Konfiguration für die Mapper einer bestimmten Registrierung ausführt.

  Referenzen: #5897

• [orm] [bug]

  Fügt eine umfassende Prüfung und eine aussagekräftige Fehlermeldung für den Fall hinzu, dass eine zugeordnete Klasse oder ein zugeordneter Klassenname als Zeichenkette an relationship.secondary übergeben wird. Dies ist ein äußerst häufiger Fehler, der eine klare Meldung erfordert.

  Zusätzlich wird eine neue Regel zur Klassenregistrierungsauflösung hinzugefügt, sodass in Bezug auf den Parameter relationship.secondary, wenn eine zugeordnete Klasse und ihre Tabelle denselben Zeichenkettennamen haben, die Table bei der Auflösung dieses Parameters bevorzugt wird. In allen anderen Fällen wird weiterhin die Klasse bevorzugt, wenn eine Klasse und eine Tabelle denselben Namen haben.

  Diese Änderung wird auch **zurückportiert** zu: 1.3.21

  Referenzen: #5774

• [orm] [bug]

  Behebt einen Fehler im Zusammenhang mit der Option restore_load_context von ORM-Ereignissen wie InstanceEvents.load(), sodass das Flag nicht an Unterklassen weitergegeben wurde, die nach der ersten Einrichtung des Ereignishandlers zugeordnet wurden.

  Diese Änderung wird auch **zurückportiert** zu: 1.3.21

  Referenzen: #5737

• [orm] [bug] [regression]

  Behebt ein Problem in der neuen Session, ähnlich wie bei der Connection, bei der die neue "autobegin"-Logik in einen re-entranten (rekursiven) Zustand geraten konnte, wenn SQL innerhalb des SessionEvents.after_transaction_create()-Ereignishook ausgeführt wurde.

  Referenzen: #5845

• [orm] [bug] [unitofwork]

  Verbessert das Topologie-Sortierungssystem der Unit of Work, sodass die Topologie-Sortierung deterministisch ist, basierend auf der Sortierung der Eingabemenge, die selbst auf der Ebene von Mappern sortiert wird, sodass dieselben Eingaben von betroffenen Mappern jedes Mal dasselbe Ergebnis liefern sollten, unter Mappern/Tabellen, die keine gegenseitige Abhängigkeit haben. Dies reduziert weiter die Wahrscheinlichkeit von Deadlocks, wie sie bei einem Flush beobachtet werden können, der zwischen mehreren, nicht zusammenhängenden Tabellen aktualisiert und dabei Sperren auf Zeilenebene generiert.

  Referenzen: #5735

• [orm] [bug]

  Behebt eine Regression, bei der das Flag Bundle.single_entity für ein Bundle wirksam wurde, auch wenn es nicht gesetzt war. Darüber hinaus ist dieses Flag veraltet, da es nur für das Query-Objekt und nicht für die 2.0-Stil-Ausführung sinnvoll ist. Eine Deprecation-Warnung wird ausgegeben, wenn es mit neuen Ausführungsstilen verwendet wird.

  Referenzen: #5702

• [orm] [bug]

  Behebt eine Regression, bei der die Erstellung einer aliased-Konstruktion gegen ein einfaches wählbares Element, das einen Namen einschließt, einen AssertionError auslöste.

  Referenzen: #5750

• [orm] [bug]

  Bezieht sich auf die Korrekturen für das Lambda-Kriteriensystem in Core. Innerhalb des ORM wurden verschiedene Korrekturen für die Funktion with_loader_criteria() sowie für den Ereignishandler SessionEvents.do_orm_execute(), der oft in Verbindung damit verwendet wird [Ticket:5760].

  • Behebt ein Problem, bei dem die Funktion with_loader_criteria() fehlschlug, wenn die angegebene Entität oder Basis nicht zugeordnete Mixins in ihrer absteigenden Klassenhierarchie enthielt [Ticket:5766].

  • Die Funktion with_loader_criteria() ist nun bedingungslos für ORM-"Refresh"-Operationen deaktiviert, einschließlich des Ladens von verzögerten oder abgelaufenen Spaltenattributen sowie für explizite Operationen wie Session.refresh(). Diese Ladevorgänge basieren notwendigerweise auf der Primärschlüsselidentität, bei der zusätzliche WHERE-Kriterien niemals angemessen sind. [Ticket:5762]

  • Fügt das neue Attribut ORMExecuteState.is_column_load hinzu, um einem SessionEvents.do_orm_execute()-Handler anzuzeigen, dass eine bestimmte Operation ein primärschlüsselorientierter Spaltenattribut-Ladevorgang ist, bei dem keine zusätzlichen Kriterien hinzugefügt werden sollten. Die Funktion with_loader_criteria() ignoriert diese nun in jedem Fall. [Ticket:5761]

  • Behebt ein Problem, bei dem das Attribut ORMExecuteState.is_relationship_load bei vielen Lazy-Loads sowie bei allen Selectinloads nicht korrekt gesetzt wurde. Das Flag ist unerlässlich, um zu prüfen, ob Optionen zu Anweisungen hinzugefügt werden sollen oder ob sie bereits über Relationship-Loads propagiert wurden. [Ticket:5764]

  Referenzen: #5760, #5761, #5762, #5764, #5766

• [orm] [bug]

  Behebt eine Regression in Version 1.4, bei der die Verwendung von Query.having() in Verbindung mit Abfragen mit intern angepassten SQL-Elementen (häufig in Vererbungsszenarien) aufgrund eines falschen Funktionsaufrufs fehlschlug. Pull-Request von esoh.

  Referenzen: #5781

• [orm] [bug]

  Behebt ein Problem, bei dem die API zur Erstellung einer benutzerdefinierten ausführbaren SQL-Konstruktion mit der Erweiterung sqlalchemy.ext.compiles gemäß der seit vielen Jahren verfügbaren Dokumentation nicht mehr funktionierte, wenn nur Executable, ClauseElement als Basisklassen verwendet wurden. Zusätzliche Klassen waren erforderlich, wenn Session.execute() verwendet werden sollte. Dies wurde behoben, sodass diese zusätzlichen Klassen nicht mehr benötigt werden.

• [orm] [bug] [regression]

  Behebt eine ORM-Unit-of-Work-Regression, bei der eine fehlerhafte "assert primary_key"-Anweisung die Primärschlüsselgenerierungssequenzen beeinträchtigt, die die Spalten in der Tabelle nicht tatsächlich als echten Primärschlüssel-Constraint betrachten, sondern stattdessen Mapper.primary_key verwenden, um bestimmte Spalten als "primär" festzulegen.

  Referenzen: #5867

orm declarative

• [orm] [declarative] [feature]

  Fügt Declarative ein alternatives Auflösungsschema hinzu, das die SQLAlchemy-Spalte oder die zugeordnete Eigenschaft aus dem "metadata"-Dictionary eines dataclasses.Field-Objekts extrahiert. Dies ermöglicht die Kombination vollständiger deklarativer Zuordnungen mit Dataclass-Feldern.

  Siehe auch

  Mapping von vorbestehenden Dataclasses mit deklarativen Feldern

  Referenzen: #5745

engine

• [engine] [feature]

  Dialektspezifische Konstrukte wie Insert.on_conflict_do_update() können nun direkt als Zeichenkette (stringify) ausgegeben werden, ohne dass ein explizites Dialektobjekt angegeben werden muss. Die Konstrukte rufen beim Aufruf von str(), print() usw. nun intern ihren entsprechenden Dialekt auf, anstatt den "Standard"-Dialekt zu verwenden, der diese nicht stringifizieren kann. Dieser Ansatz wird auch auf generische schemaweite Create/Drop-Operationen wie AddConstraint angewendet, das seinen Stringify-Dialekt an den durch das darin enthaltene Element angegebenen Dialekt anpasst, wie z. B. das Objekt ExcludeConstraint.

• [engine] [feature]

  Fügt die neue Ausführungsoption Connection.execution_options.logging_token hinzu. Diese Option fügt eine zusätzliche Token pro Nachricht zu den Protokollmeldungen hinzu, die von der Connection bei der Ausführung von Anweisungen generiert werden. Dieses Token ist kein Teil des Logger-Namens selbst (der kann über den vorhandenen Parameter create_engine.logging_name beeinflusst werden), sodass es für die Ad-hoc-Nutzung von Verbindungen geeignet ist, ohne die Nebenwirkung der Erstellung vieler neuer Logger. Die Option kann auf der Ebene von Connection oder Engine gesetzt werden.

  Siehe auch

  Pro-Verbindung / Sub-Engine-Token setzen

  Referenzen: #5911

• [engine] [bug] [sqlite]

  Behebt einen Fehler in der 2.0 "future"-Version von Engine, bei dem das Ausgeben von SQL während des EngineEvents.begin()-Ereignishooks aufgrund von Autobegin zu einer re-entranten (rekursiven) Bedingung führte, die unter anderem das für SQLite dokumentierte Rezept zur Unterstützung von Savepoints und seriellem Isolation beeinflusste.

  Referenzen: #5845

• [engine] [bug] [oracle] [postgresql]

  Passt die "setinputsizes"-Logik an, die von den cx_Oracle-, asyncpg- und pg8000-Dialekten verwendet wird, um einen TypeDecorator zu unterstützen, der eine Überschreibung der Methode TypeDecorator.get_dbapi_type() enthält.

• [engine] [bug]

  Fügt das Schlüsselwort "future" zur Liste der Wörter hinzu, die von der Funktion engine_from_config() bekannt sind, sodass die Werte "true" und "false" als "boolesche" Werte konfiguriert werden können, wenn ein Schlüssel wie sqlalchemy.future = true oder sqlalchemy.future = false verwendet wird.

sql

• [sql] [feature]

  Implementiert Unterstützung für "table valued functions" sowie zusätzliche Syntaxen, die von PostgreSQL unterstützt werden, eine der am häufigsten nachgefragten Funktionen. Table-valued functions sind SQL-Funktionen, die Listen von Werten oder Zeilen zurückgeben und in PostgreSQL im Bereich der JSON-Funktionen weit verbreitet sind, wo der "tabellarische Wert" üblicherweise als "record"-Datentyp bezeichnet wird. Table-valued functions werden auch von Oracle und SQL Server unterstützt.

  Zu den hinzugefügten Funktionen gehören:

  • der Modifikator FunctionElement.table_valued(), der ein tabellenähnliches wählbares Objekt aus einer SQL-Funktion erstellt.

  • Eine TableValuedAlias-Konstruktion, die eine SQL-Funktion als benannte Tabelle rendert.

  • Unterstützung für die spezielle PostgreSQL-Syntax für "derived column", die Spaltennamen und manchmal Datentypen enthält, wie z. B. für die Funktion json_to_recordset, unter Verwendung der Methode TableValuedAlias.render_derived().

  • Unterstützung für PostgreSQLs "WITH ORDINALITY"-Konstrukt unter Verwendung des Parameters FunctionElement.table_valued.with_ordinality.

  • Unterstützung für die Auswahl FROM einer tabellarischen Funktion als spaltenwertiges Skalar, eine Syntax, die von PostgreSQL und Oracle unterstützt wird, über die Methode FunctionElement.column_valued().

  • Eine Möglichkeit, eine einzelne Spalte aus einem tabellarischen Ausdruck auszuwählen, ohne eine FROM-Klausel zu verwenden, über die Methode FunctionElement.scalar_table_valued().

  Siehe auch

  Tabellenwertige Funktionen - im SQLAlchemy Unified Tutorial

  Referenzen: #3566

• [sql] [usecase]

  Mehrfache Aufrufe von "returning", z. B. Insert.returning(), können nun verkettet werden, um der RETURNING-Klausel neue Spalten hinzuzufügen.

  Referenzen: #5695

• [sql] [usecase]

  Fügt die Methode Select.outerjoin_from() hinzu, um Select.join_from() zu ergänzen.

• [sql] [usecase]

  Passt die "literal_binds"-Funktion von Compiler an, um NULL für einen gebundenen Parameter mit dem Wert None zu rendern, sei es explizit übergeben oder weggelassen. Die vorherige Fehlermeldung "bind parameter without a renderable value" wird entfernt, und ein fehlender oder None-Wert rendert nun in allen Fällen NULL. Zuvor begann die Darstellung von NULL für DML-Anweisungen aufgrund interner Refaktorierungen, war aber nicht explizit Teil der Testabdeckung, was sie nun ist.

  Obwohl kein Fehler ausgelöst wird, wird, wenn der Kontext innerhalb eines Spaltenvergleichs liegt und der Operator nicht "IS"/"IS NOT" ist, eine Warnung ausgegeben, dass dies aus SQL-Sicht im Allgemeinen nicht nützlich ist.

  Referenzen: #5888

• [sql] [bug]

  Behobenes Problem in der neuen Methode Select.join(), bei der das Verketten von der aktuellen JOIN die falsche Zustandsinformation betrachtete, was zu einem Ausdruck wie „FROM a JOIN b <onclause>, b JOIN c <onclause>“ anstelle von „FROM a JOIN b <onclause> JOIN c <onclause>“ führte.

  Referenzen: #5858

• [sql] [bug]

  Deprecation-Warnungen werden im Modus „SQLALCHEMY_WARN_20“ ausgegeben, wenn ein einfacher String an Session.execute() übergeben wird.

  Referenzen: #5754

• [sql] [bug] [orm]

  Eine Vielzahl von Korrekturen an der „Lambda SQL“-Funktion, die unter Verwendung von Lambdas zur signifikanten Beschleunigung der Statement-Generierung eingeführt wurde, wurden basierend auf Benutzerfeedback implementiert, mit einem Schwerpunkt auf ihrer Verwendung innerhalb der Funktion with_loader_criteria(), wo sie am prominentesten eingesetzt wird [ticket:5760]

  • Behobenes Problem, bei dem boolesche True/False-Werte, auf die in den Closure-Variablen der Lambda verwiesen wurde, Fehler verursachten. [ticket:5763]

  • Korrigierte eine nicht funktionierende Erkennung für Python-Funktionen, die in das Lambda eingebettet waren und gebundene Werte erzeugten; dieser Fall ist wahrscheinlich nicht unterstützbar, sodass ein informativer Fehler ausgelöst wird, und die Funktion sollte außerhalb des Lambdas selbst aufgerufen werden. Neue Dokumentation wurde hinzugefügt, um dieses Verhalten weiter zu erläutern. [ticket:5770]

  • Das Lambda-System lehnt standardmäßig die Verwendung von Nicht-SQL-Elementen innerhalb der Closure-Variablen des Lambdas vollständig ab, wobei der Fehler die beiden Optionen vorschlägt, entweder explizit Closure-Variablen zu ignorieren, die keine SQL-Parameter sind, oder eine spezifische Menge von Werten anzugeben, die als Teil des Cache-Schlüssels basierend auf dem Hashwert betrachtet werden sollen. Dies verhindert kritisch, dass das Lambda-System annimmt, dass beliebige Objekte innerhalb der Closure des Lambdas für das Caching geeignet sind, während es sie standardmäßig auch nicht ignoriert, was den Fall verhindert, dass ihr Zustand nicht konstant ist und sich auf das erzeugte SQL-Konstrukt auswirkt. Die Fehlermeldung ist umfassend und neue Dokumentation wurde hinzugefügt, um dieses Verhalten weiter zu erläutern. [ticket:5765]

  • Unterstützung für den Randfall korrigiert, bei dem ein Ausdruck in_() gegen eine Liste von SQL-Elementen, wie z.B. literal()-Objekte, nicht korrekt berücksichtigt wurde. [ticket:5768]

  Referenzen: #5760, #5763, #5765, #5768, #5770

• [sql] [bug] [mysql] [postgresql] [sqlite]

  Eine informative Fehlermeldung wird nun für eine ausgewählte Menge von DML-Methoden (derzeit alle Teil von Insert-Konstrukten) ausgegeben, wenn sie ein zweites Mal aufgerufen werden, was implizit die vorherige Einstellung aufheben würde. Die geänderten Methoden umfassen: on_conflict_do_update, on_conflict_do_nothing (SQLite), on_conflict_do_update, on_conflict_do_nothing (PostgreSQL), on_duplicate_key_update (MySQL)

  Referenzen: #5169

• [sql] [bug]

  Behobenes Problem im neuen Konstrukt Values, bei dem die Übergabe von Tupeln von Objekten auf die Typenerkennung pro Wert zurückfiel, anstatt die direkt an Values übergebenen Column-Objekte zu nutzen, die SQLAlchemy mitteilen, welchen Typ es erwartet. Dies führte zu Problemen bei Objekten wie Enums und Numpy-Strings, die nicht tatsächlich notwendig waren, da der erwartete Typ angegeben wurde.

  Referenzen: #5785

• [sql] [bug]

  Behobenes Problem, bei dem eine RemovedIn20Warning fälschlicherweise ausgegeben wurde, wenn auf das Attribut .bind intern auf Objekten zugegriffen wurde, insbesondere beim Stringifizieren eines SQL-Konstrukts.

  Referenzen: #5717

• [sql] [bug]

  Korrekte Darstellung von cycle=False und order=False als NO CYCLE und NO ORDER in Sequence- und Identity-Objekten.

  Referenzen: #5722

• [sql]

  Ersetzt Query.with_labels() und GenerativeSelect.apply_labels() durch explizite Getter und Setter GenerativeSelect.get_label_style() und GenerativeSelect.set_label_style(), um die drei unterstützten Label-Stile zu unterstützen: LABEL_STYLE_DISAMBIGUATE_ONLY, LABEL_STYLE_TABLENAME_PLUS_COL und LABEL_STYLE_NONE.

  Darüber hinaus ist für Core und ORM-Abfragen im „Future Style“ LABEL_STYLE_DISAMBIGUATE_ONLY nun der Standard-Label-Stil. Dieser Stil unterscheidet sich vom bestehenden Stil „keine Labels“ darin, dass Labels bei Namenskonflikten von Spalten angewendet werden; bei LABEL_STYLE_NONE ist eine doppelte Spalte in keinem Fall per Name zugänglich.

  Für Fälle, in denen die Benennung wichtig ist, insbesondere dass die .c-Sammlung einer Unterabfrage alle Spalten eindeutig referenzieren kann, ist das Verhalten von LABEL_STYLE_DISAMBIGUATE_ONLY nun für alle SQLAlchemy-Funktionen über Core und ORM hinweg ausreichend, die dieses Verhalten beinhalten. Ergebniszeilen seit SQLAlchemy 1.0 sind normalerweise positionsbezogen an Spaltenkonstrukte angeglichen.

  Für Legacy-ORM-Abfragen mit Query wird der Tabellen-plus-Spaltennamen-Label-Stil, der von LABEL_STYLE_TABLENAME_PLUS_COL angewendet wird, weiterhin verwendet, damit bestehende Test-Suites und Logging-Einrichtungen standardmäßig keine Verhaltensänderungen sehen.

  Referenzen: #4757

schema

• [schema] [feature]

  Hinzugefügt TypeEngine.as_generic() zur Abbildung von dialektspezifischen Typen, wie z.B. sqlalchemy.dialects.mysql.INTEGER, auf den „besten passenden“ generischen SQLAlchemy-Typ, in diesem Fall Integer. Pull Request von Andrew Hannigan.

  Siehe auch

  Reflexion mit datenbankagnostischen Typen - Beispielverwendung

  Referenzen: #5659

• [schema] [usecase]

  Das Ereignis DDLEvents.column_reflect() kann nun auf ein MetaData-Objekt angewendet werden, wo es für die Table-Objekte innerhalb dieser Sammlung wirksam wird.

  Siehe auch

  DDLEvents.column_reflect()

  Automatisierung von Spaltennamensschemata aus reflektierten Tabellen - in der ORM-Mapping-Dokumentation

  Abfangen von Spaltendefinitionen - in der Automap-Dokumentation

  Referenzen: #5712

• [schema] [usecase]

  Hinzugefügt wurden die Parameter CreateTable.if_not_exists, CreateIndex.if_not_exists, DropTable.if_exists und DropIndex.if_exists zu den Konstrukten CreateTable, DropTable, CreateIndex und DropIndex, die „IF NOT EXISTS“ / „IF EXISTS“ DDL zu den CREATE/DROP-Befehlen hinzufügen. Diese Phrasen werden nicht von allen Datenbanken akzeptiert und der Vorgang schlägt auf einer Datenbank fehl, die sie nicht unterstützt, da keine ähnlich kompatible Fallback-Lösung im Geltungsbereich einer einzelnen DDL-Anweisung existiert. Pull Request von Ramon Williams.

  Referenzen: #2843

• [schema] [changed]

  Änderung des Verhaltens des Konstrukts Identity, sodass bei Anwendung auf eine Column automatisch angenommen wird, dass der Wert von Column.nullable auf False gesetzt wird, ähnlich wie wenn der Parameter Column.primary_key auf True gesetzt ist. Dies entspricht dem Standardverhalten aller unterstützenden Datenbanken, bei denen IDENTITY NOT NULL impliziert. Das PostgreSQL-Backend ist das einzige, das das Hinzufügen von NULL zu einer IDENTITY-Spalte unterstützt, was hier durch Übergabe eines True-Wertes für den Parameter Column.nullable gleichzeitig unterstützt wird.

  Referenzen: #5775

asyncio

• [asyncio] [usecase]

  Die Objekte AsyncEngine, AsyncConnection und AsyncTransaction können mit Python == oder != verglichen werden, wobei die beiden gegebenen Objekte basierend auf dem „sync“-Objekt verglichen werden, das sie repräsentieren. Dies ist nützlich, da es insbesondere bei AsyncTransaction Fälle gibt, in denen mehrere Instanzen von AsyncTransaction auf dieselbe sync Transaction repräsentieren und tatsächlich äquivalent sind. Die Methode AsyncConnection.get_transaction() gibt derzeit jedes Mal einen neuen, repräsentierenden AsyncTransaction zurück, da die AsyncTransaction ansonsten nicht zustandsbezogen mit ihrer Ursprungs-AsyncConnection verbunden ist.

• [asyncio] [bug]

  Die Greenlet-Integration, die Unterstützung für Python asyncio in SQLAlchemy bietet, wurde angepasst, um die Verarbeitung von Python contextvars (eingeführt in Python 3.7) für greenlet-Versionen größer als 0.4.17 zu unterstützen. Greenlet Version 0.4.17 fügte eine automatische Verarbeitung von Contextvars auf eine abwärtsinkompatible Weise hinzu; wir haben uns mit den Greenlet-Autoren abgestimmt, um eine bevorzugte API dafür in Versionen nach 0.4.17 hinzuzufügen, die nun von der Greenlet-Integration von SQLAlchemy unterstützt wird. Für Greenlet-Versionen vor 0.4.17 ist keine Verhaltensänderung erforderlich, Version 0.4.17 selbst ist von den Abhängigkeiten ausgeschlossen.

  Referenzen: #5615

• [asyncio] [bug]

  Implementiertes „Connection-Binding“ für AsyncSession, die Möglichkeit, eine AsyncConnection zu übergeben, um eine AsyncSession zu erstellen. Zuvor war dieser Anwendungsfall nicht implementiert und verwendete die zugeordnete Engine, wenn die Verbindung übergeben wurde. Dies behebt das Problem, dass der Anwendungsfall „eine Sitzung an eine externe Transaktion binden“ für die AsyncSession nicht korrekt funktionierte. Zusätzlich wurden die Methoden AsyncConnection.in_transaction(), AsyncConnection.in_nested_transaction(), AsyncConnection.get_transaction(), AsyncConnection.get_nested_transaction() und das Attribut AsyncConnection.info hinzugefügt.

  Referenzen: #5811

• [asyncio] [bug]

  Behobenes Problem im asyncio-Verbindungspool, bei dem asyncio.TimeoutError anstelle von TimeoutError ausgelöst wurde. Auch der Parameter create_engine.pool_timeout wurde auf Null gesetzt, wenn die asynchrone Engine verwendet wurde, was zuvor das Timeout ignorierte und blockierte, anstatt sofort zu timen, wie es bei der regulären QueuePool der Fall ist.

  Referenzen: #5827

• [asyncio] [bug] [pool]

  Bei Verwendung einer asynchronen Engine wird der Verbindungspool nun eine gepoolte Verbindung, die nicht explizit geschlossen/an den Pool zurückgegeben wurde, beim Garbagecollecten ihres Tracking-Objekts trennen und verwerfen und eine Warnung ausgeben, dass die Verbindung nicht ordnungsgemäß geschlossen wurde. Da dieser Vorgang während der Python-GC-Finalizer stattfindet, ist es nicht sicher, IO-Operationen auf der Verbindung durchzuführen, einschließlich Transaktions-Rollback oder Verbindungsabbau, da dies oft außerhalb der Event-Schleife geschieht.

  Die standardmäßig auf asynchronen dpapis verwendete AsyncAdaptedQueue instanziiert eine Queue nur, wenn sie zum ersten Mal verwendet wird, um sie an eine möglicherweise falsche Event-Schleife zu binden.

  Referenzen: #5823

• [asyncio]

  Der asynchrone Modus von SQLAlchemy erkennt und löst nun einen informativen Fehler aus, wenn eine nicht asynchron kompatible DBAPI verwendet wird. Die Verwendung einer Standard-DBAPI mit asynchronem SQLAlchemy führt dazu, dass diese blockiert, wie jeder synchrone Aufruf, und unterbricht die ausführende asyncio-Schleife.

postgresql

• [postgresql] [usecase]

  Hinzugefügt wurde der neue Parameter ExcludeConstraint.ops zum Objekt ExcludeConstraint zur Unterstützung der Angabe von Operator-Klassen für diese Einschränkung. Pull Request von Alon Menczer.

  Diese Änderung wird auch **zurückportiert** zu: 1.3.21

  Referenzen: #5604

• [postgresql] [usecase]

  Hinzugefügt wurde ein Lese-/Schreibattribut .autocommit zur DBAPI-Adapter-Schicht für den asyncpg-Dialekt. Dies dient dazu, dass bei der Arbeit mit DBAPI-spezifischen Schemata, die „autocommit“ direkt mit der DBAPI-Verbindung verwenden müssen, dasselbe .autocommit-Attribut verfügbar ist, das sowohl mit psycopg2 als auch mit pg8000 funktioniert.

• [postgresql] [changed]

  Behobenes Problem, bei dem der psycopg2-Dialekt das Flag use_native_unicode=False stillschweigend übergab, ohne unter Python 3 tatsächlich eine Wirkung zu erzielen, da die psycopg2 DBAPI unter Python 3 Unicode bedingungslos verwendet. Diese Verwendung löst nun einen ArgumentError aus, wenn sie unter Python 3 verwendet wird. Testunterstützung für Python 2 wurde hinzugefügt.

• [postgresql] [performance]

  Verbesserung der Leistung des asyncpg-Dialekts durch Caching der asyncpg PreparedStatement-Objekte pro Verbindung. Für einen Testfall, der dieselbe Anweisung auf einer Menge von gepoolten Verbindungen verwendet, scheint dies eine Leistungssteigerung von 10-20 % zu erzielen. Die Cache-Größe ist einstellbar und kann auch deaktiviert werden.

  Siehe auch

  Prepared Statement Cache

• [postgresql] [bug] [mysql]

  Behobene Regression, die in 1.3.22 für den PostgreSQL-Dialekt eingeführt wurde und auch in die Funktion des MySQL-Dialekts in 1.3.18 kopiert wurde, bei der die Verwendung eines Nicht-Table-Konstrukts wie text() als Argument für Select.with_for_update.of nicht korrekt in den PostgreSQL- oder MySQL-Compilern berücksichtigt wurde.

  Diese Änderung wird auch **zurückportiert** zu: 1.3.21

  Referenzen: #5729

• [postgresql] [bug]

  Behobene kleine Regression, bei der die Abfrage für „show standard_conforming_strings“ bei der Initialisierung auch dann ausgegeben wurde, wenn die Serverversion-Info als kleiner als Version 8.2 erkannt wurde; zuvor trat dies nur für Serverversionen ab 8.2 auf. Die Abfrage schlägt auf Amazon Redshift fehl, das eine PG-Serverversion kleiner als dieser Wert meldet.

  Referenzen: #5698

• [postgresql] [bug]

  Unterstützung für Column-Objekte sowie für ORM-instrumentierte Attribute als Schlüssel im Wörterbuch set_, das an die Methoden Insert.on_conflict_do_update() und Insert.on_conflict_do_update() übergeben wird, eingeführt, die den Column-Objekten in der .c-Sammlung der Ziel-Table entsprechen. Zuvor wurden nur Zeichenketten-Spaltennamen erwartet; ein Spaltenausdruck wurde als ein Ausdruck außerhalb der Tabelle angenommen, der vollständig mit einer Warnung gerendert wurde.

  Referenzen: #5722

• [postgresql] [bug] [asyncio]

  Behobenes Problem im asyncpg-Dialekt, bei dem ein Fehler während eines „Commit“ oder unwahrscheinlicher eines „Rollback“ die gesamte Transaktion abbrechen sollte; es ist nicht mehr möglich, ein Rollback auszulösen. Zuvor wartete die Verbindung weiterhin auf ein Rollback, das nicht erfolgreich sein konnte, da asyncpg es ablehnte.

  Referenzen: #5824

mysql

• [mysql] [feature]

  Hinzugefügt wurde Unterstützung für den aiomysql-Treiber bei der Verwendung der asyncio SQLAlchemy-Erweiterung.

  Siehe auch

  aiomysql

  Referenzen: #5747

• [mysql] [bug] [reflection]

  Behobenes Problem, bei dem die Reflexion eines Server-Defaults nur auf MariaDB, der einen Dezimalpunkt im Wert enthielt, nicht korrekt reflektiert wurde, was zu einer reflektierten Tabelle führte, der ein Server-Standard fehlte.

  Diese Änderung wird auch **zurückportiert** zu: 1.3.21

  Referenzen: #5744

sqlite

• [sqlite] [usecase]

  Implementiert die Klausel INSERT… ON CONFLICT für SQLite. Pull Request von Ramon Williams.

  Siehe auch

  INSERT…ON CONFLICT (Upsert)

  Referenzen: #4010

• [sqlite] [bug]

  Verwendet Python re.search() anstelle von re.match() für die Operation der Methode Column.regexp_match() bei Verwendung von SQLite. Dies entspricht dem Verhalten von regulären Ausdrücken auf anderen Datenbanken sowie dem von bekannten SQLite-Plugins.

  Referenzen: #5699

mssql

• [mssql] [bug] [datatypes] [mysql]

  Die Genauigkeit und das Verhalten von Dezimalzahlen wurden beim Extrahieren von Fließkomma- und/oder Dezimalwerten aus JSON-Strings mit der Methode Comparator.as_float() verbessert, wenn der numerische Wert innerhalb des JSON-Strings viele signifikante Stellen hat; zuvor schnitten MySQL-Backends Werte mit vielen signifikanten Stellen ab und SQL Server-Backends lösten aufgrund eines DECIMAL-Casts mit unzureichenden signifikanten Stellen eine Ausnahme aus. Beide Backends verwenden nun einen FLOAT-kompatiblen Ansatz, der keine signifikanten Stellen für Fließkommawerte festlegt. Für präzise numerische Werte wurde eine neue Methode Comparator.as_numeric() hinzugefügt, die Argumente für Präzision und Skala akzeptiert und Werte als Python Decimal-Objekte ohne Fließkommakonvertierung zurückgibt, vorausgesetzt, die DBAPI unterstützt dies (alle außer pysqlite).

  Referenzen: #5788

oracle

• [oracle] [bug]

  Behobene Regression, die aufgrund von #5755 aufgetreten ist, welche die Unterstützung für Isolationsebenen für Oracle implementiert hat. Es wurde berichtet, dass viele Oracle-Konten nicht die Berechtigung haben, die Ansicht v$transaction abzufragen, daher wurde diese Funktion so geändert, dass sie bei Fehlschlägen bei der Datenbankverbindung nach einem Fallback sucht. Der Dialekt geht davon aus, dass „READ COMMITTED“ die Standard-Isolationsebene ist, wie es vor SQLAlchemy 1.3.21 der Fall war. Die explizite Verwendung der Methode Connection.get_isolation_level() muss nun zwangsläufig eine Ausnahme auslösen, da Oracle-Datenbanken mit dieser Einschränkung dem Benutzer explizit das Lesen der aktuellen Isolationsebene verweigern.

  Diese Änderung wird auch **zurückportiert** nach: 1.3.22

  Referenzen: #5784

• [oracle] [bug]

  Oracle-Zwei-Phasen-Transaktionen auf rudimentärer Ebene sind nun nicht mehr veraltet. Nach Erhalt von Unterstützung durch die cx_Oracle-Entwickler können wir grundlegende xid + begin/prepare-Unterstützung mit einigen Einschränkungen anbieten, die in einer zukünftigen Version von cx_Oracle besser funktionieren werden. Zwei-Phasen-„Recovery“ wird derzeit nicht unterstützt.

  Referenzen: #5884

• [oracle] [bug]

  Der Oracle-Dialekt verwendet nun select sys_context( 'userenv', 'current_schema' ) from dual, um den Standard-Schema-Namen zu erhalten, anstatt SELECT USER FROM DUAL, um Änderungen am sitzungslokalen Schema-Namen unter Oracle zu berücksichtigen.

  Referenzen: #5716

tests

• [tests] [usecase] [pool]

  Verbesserte Dokumentation und Hinzufügen von Tests für Pool-Timeouts unter einer Sekunde. Pull Request von Jordan Pittier.

  Referenzen: #5582

misc

• [usecase] [pool]

  Die internen Mechanismen der Engine-Verbindungsroutine wurden geändert, sodass garantiert ist, dass ein benutzerdefinierter Ereignisbehandler für den PoolEvents.connect()-Behandler, wenn er mit insert=True eingerichtet wird, einen Ereignisbehandler ausführen lässt, der definitiv vor jeder dialektspezifischen Initialisierung aufgerufen wird, insbesondere wenn Dinge wie die Erkennung des Standard-Schema-Namens erfolgen. Zuvor geschah dies in den meisten Fällen, aber nicht bedingungslos. Ein neues Beispiel wurde zur Schema-Dokumentation hinzugefügt, das zeigt, wie der „Standard-Schema-Name“ innerhalb eines On-Connect-Ereignisses eingerichtet wird.

  Referenzen: #5497, #5708

• [bug] [reflection]

  Fehler behoben, bei dem der jetzt veraltete Parameter autoload intern innerhalb der Reflexionsroutinen aufgerufen wurde, wenn eine zugehörige Tabelle reflektiert wurde.

  Referenzen: #5684

• [bug] [pool]

  Regressiver Fehler behoben, bei dem ein Verbindungs-Pool-Ereignis, das mit einem Schlüsselwort angegeben wurde, insbesondere insert=True, verloren ging, als das Ereignis eingerichtet wurde. Dies verhinderte, dass Startereignisse, die vor dialektbezogenen Ereignissen ausgelöst werden müssen, korrekt funktionierten.

  Referenzen: #5708

• [bug] [pool] [pypy]

  Problem behoben, bei dem der Verbindungs-Pool Verbindungen nicht an den Pool zurückgab oder anderweitig bei der Garbage Collection unter PyPy finalisierte, wenn die ausgecheckte Verbindung außer Reichweite geriet, ohne geschlossen worden zu sein. Dies ist ein langjähriges Problem aufgrund des unterschiedlichen GC-Verhaltens von PyPy, das keine Weakref-Finalizer aufruft, wenn sie sich auf ein anderes Objekt beziehen, das ebenfalls garbage collected wird. Eine starke Referenz auf den zugehörigen Datensatz wird nun aufrechterhalten, sodass die Weakref eine stark referenzierte „Basis“ zum Auslösen hat.

  Referenzen: #5842

1.4.0b1

Veröffentlicht: 2. November 2020

general

• [general] [change]

  „python setup.py test“ ist kein Test-Runner mehr, da dies von Pypa veraltet ist. Bitte verwenden Sie „tox“ ohne Argumente für einen einfachen Testlauf.

  Referenzen: #4789

• [general] [bug]

  Die internen Konventionen für den Import von Modulen mit gegenseitigen Abhängigkeiten wurden refaktoriert, sodass die inspizierten Argumente von Funktionen und Methoden nicht mehr modifiziert werden. Dies ermöglicht Werkzeugen wie Pylint, Pycharm, anderen Code-Lintern sowie hypothetischen Pep-484-Implementierungen, die in Zukunft hinzugefügt werden, korrekt zu funktionieren, da sie keine fehlenden Argumente für Funktionsaufrufe mehr sehen. Der neue Ansatz ist auch einfacher und performanter.

  Siehe auch

  Interne Importkonventionen repariert, damit Code-Linter korrekt funktionieren

  Referenzen: #4656, #4689

platform

• [platform] [change]

  Die Bibliothek importlib_metadata wird verwendet, um nach Setuptools-Entrypoints zu suchen, anstelle von pkg_resources. Da importlib_metadata eine kleine Bibliothek ist, die ab Python 3.8 enthalten ist, wird die Kompatibilitätsbibliothek für Python-Versionen älter als 3.8 als Abhängigkeit installiert.

  Referenzen: #5400

• [platform] [change]

  Die Installation wurde modernisiert und verwendet nun setup.cfg für die meisten Paketmetadaten.

  Referenzen: #5404

• [platform] [removed]

  Unterstützung für Python 3.4 und 3.5, die das Ende ihrer Lebensdauer erreicht haben, wurde entfernt. Die SQLAlchemy 1.4-Serie erfordert Python 2.7 oder 3.6+.

  Siehe auch

  Python 3.6 ist die minimale Python-3-Version; Python 2.7 wird weiterhin unterstützt

  Referenzen: #5634

• [platform] [removed]

  Alle Dialekt-Code zur Unterstützung von Jython und zxJDBC wurden entfernt. Jython wird von SQLAlchemy seit vielen Jahren nicht mehr unterstützt und es wird nicht erwartet, dass der aktuelle zxJDBC-Code überhaupt funktionsfähig ist; vorerst nimmt er nur Platz ein und sorgt für Verwirrung, indem er in der Dokumentation erscheint. Derzeit scheint es, dass Jython die Unterstützung für Python 2.7 in seinen Veröffentlichungen erreicht hat, aber nicht für Python 3. Wenn Jython erneut unterstützt werden sollte, sollte dies in Form der Python-3-Version von Jython geschehen, und die verschiedenen zxJDBC-Stubs für verschiedene Backends sollten als Dialekt von Drittanbietern implementiert werden.

  Referenzen: #5094

orm

• [orm] [feature]

  Die ORM kann nun Abfragen generieren, die zuvor nur bei Verwendung von Query verfügbar waren, direkt über die select()-Konstruktion. Ein neues System, mit dem ORM-„Plugins“ sich innerhalb einer Core Select etablieren können, ermöglicht es, dass die meisten Abfrageerstellungslogiken, die sich zuvor in Query befanden, nun innerhalb einer Kompilierungs-Level-Erweiterung für Select stattfinden. Ähnliche Änderungen wurden auch für die Update- und Delete-Konstruktionen vorgenommen. Die Konstruktionen, wenn sie über Session.execute() aufgerufen werden, führen nun ORM-bezogene Arbeiten innerhalb der Methode aus. Für Select enthält das zurückgegebene Result-Objekt nun ORM-Level-Entitäten und Ergebnisse.

  Siehe auch

  ORM Query ist intern mit select, update, delete vereinheitlicht; 2.0-Stil-Ausführung verfügbar

  Referenzen: #5159

• [orm] [feature]

  Hinzugefügt wurde die Möglichkeit, beliebige Kriterien zur ON-Klausel hinzuzufügen, die von einem Beziehungsattribut in einer Abfrage generiert wird. Dies gilt für Methoden wie Query.join() sowie für Ladeoptionen wie joinedload(). Zusätzlich erlaubt eine „globale“ Version der Option, Kriterien auf bestimmte Entitäten in einer Abfrage global anzuwenden.

  Siehe auch

  Kriterien zu Loader-Optionen hinzufügen

  Hinzufügen globaler WHERE / ON-Kriterien

  with_loader_criteria()

  Referenzen: #4472

• [orm] [feature]

  Das ORM Declarative-System wurde in die ORM selbst integriert, mit neuen Importbereichen unter sqlalchemy.orm und neuen Arten von Mappings. Unterstützung für Decorator-basierte Mappings ohne Verwendung einer Basisklasse, Unterstützung für klassische mapper()-Aufrufe mit Zugriff auf die deklarative Klassenregistrierung für Beziehungen und volle Integration von Declarative mit 3rd-Party-Klassenattributsystemen wie dataclasses und attrs wird nun unterstützt.

  Siehe auch

  Deklarativ ist jetzt in die ORM integriert mit neuen Funktionen

  Python Dataclasses, attrs unterstützt mit Deklarativen und Imperativen Mappings

  Referenzen: #5508

• [orm] [feature]

  Eager-Loader, wie joined loading, SELECT IN loading usw., wenn sie auf einem Mapper oder über Abfrageoptionen konfiguriert sind, werden nun während des Refreshs eines abgelaufenen Objekts aufgerufen; im Falle von selectinload und subqueryload wird, da die zusätzliche Ladung nur für ein einzelnes Objekt erfolgt, hierbei das „immediateload“-Schema verwendet, das der Abfrage ähnelt, die von lazy loading ausgesendet wird.

  Siehe auch

  Eager-Loader werden bei Unexpire-Vorgängen ausgelöst

  Referenzen: #1763

• [orm] [feature]

  Unterstützung für die direkte Abbildung von Python-Klassen, die mit dem Python-Decorator dataclasses definiert sind, wurde hinzugefügt. Pull Request von Václav Klusák. Das neue Feature integriert sich in die neue Unterstützung auf Deklarationsebene für Systeme wie dataclasses und attrs.

  Siehe auch

  Python Dataclasses, attrs unterstützt mit Deklarativen und Imperativen Mappings

  Deklarativ ist jetzt in die ORM integriert mit neuen Funktionen

  Referenzen: #5027

• [orm] [feature]

  Die Funktion „raiseload“ für ORM-abgebildete Spalten wurde über den Parameter defer.raiseload in defer() und deferred() hinzugefügt. Dies bietet ein ähnliches Verhalten für spaltenausdrucksabgebildete Attribute wie die Option raiseload() für beziehungsabgebildete Attribute. Die Änderung beinhaltet auch einige Verhaltensänderungen bei verzögerten Spalten in Bezug auf den Ablauf; siehe Migrationshinweise für Details.

  Siehe auch

  Raiseload für Spalten

  Referenzen: #4826

• [orm] [usecase]

  Der Evaluator, der bei der ORM-Bulk-Aktualisierung und -Löschung für synchronize_session=„evaluate“ stattfindet, unterstützt nun die Operatoren IN und NOT IN. Tuple IN wird ebenfalls unterstützt.

  Referenzen: #1653

• [orm] [usecase]

  Erweiterte Logik, die verfolgt, ob Beziehungen miteinander kollidieren, wenn sie in dieselbe Spalte schreiben, um einfache Fälle von zwei Beziehungen, die eine „Backref“ zwischen sich haben sollten, einzubeziehen. Das bedeutet, dass, wenn zwei Beziehungen nicht viewonly sind, nicht mit back_populates verknüpft sind und sich nicht in einer erbenden Geschwister-/Überschreibungsanordnung befinden und dieselbe Fremdschlüsselspalte füllen, eine Warnung bei der Mapper-Konfiguration ausgegeben wird, die darauf hinweist, dass eine Kollision auftreten könnte. Ein neuer Parameter relationship.overlaps wird hinzugefügt, um diese sehr seltenen Fälle zu berücksichtigen, in denen eine solche überlappende Persistenzanordnung unvermeidlich sein kann.

  Referenzen: #5171

• [orm] [usecase]

  Die ORM-Bulk-Aktualisierungs- und -Löschoperationen, die historisch über die Methoden Query.update() und Query.delete() sowie über die Konstruktionen Update und Delete für die Ausführung im 2.0-Stil verfügbar sind, berücksichtigen nun automatisch die zusätzlichen WHERE-Kriterien, die für einen Single-Table-Inheritance-Diskriminator erforderlich sind, um die Anweisung auf Zeilen zu beschränken, die sich auf den angeforderten spezifischen Untertyp beziehen. Die neue with_loader_criteria()-Konstruktion wird ebenfalls für Bulk-Aktualisierungs-/Löschoperationen unterstützt.

  Referenzen: #3903, #5018

• [orm] [usecase]

  Das Flag relationship.sync_backref in einer Beziehung wurde aktualisiert, um es bei viewonly=True-Beziehungen implizit auf False zu setzen und Synchronisierungsereignisse zu verhindern.

  Siehe auch

  Viewonly-Beziehungen synchronisieren keine Backrefs

  Referenzen: #5237

• [orm] [change]

  Die Bedingung, bei der ein schwebendes Objekt mit einer Identität, die bereits in der Identitätskarte vorhanden ist, geflusht wird, wurde angepasst, um eine Warnung auszugeben, anstatt einen FlushError auszulösen. Die Begründung dafür ist, dass der Flush fortgesetzt wird und stattdessen ein IntegrityError ausgelöst wird, genauso als ob das vorhandene Objekt nicht bereits in der Identitätskarte vorhanden wäre. Dies hilft bei Schemata, die den IntegrityError als Mittel verwenden, um zu erfassen, ob eine Zeile bereits in der Tabelle vorhanden ist oder nicht.

  Siehe auch

  Der Fehler „New instance conflicts with existing identity“ ist nun eine Warnung

  Referenzen: #4662

• [orm] [change] [sql]

  Eine Auswahl von Core- und ORM-Abfrageobjekten führt nun viel mehr ihrer Python-Berechnungsaufgaben in der Kompilierungsphase durch, anstatt zur Konstruktionszeit. Dies dient zur Unterstützung eines zukünftigen Caching-Modells, das das Caching der kompilierten Anweisungsstruktur basierend auf einem Cache-Schlüssel ermöglicht, der aus der Anweisungskonstruktion abgeleitet wird, die selbst bei jeder Verwendung neu in Python-Code konstruiert wird. Dies bedeutet, dass der interne Zustand dieser Objekte möglicherweise nicht derselbe ist wie früher, und dass einige, aber nicht alle Fehlerlösungszenarien für verschiedene Arten von Argumentvalidierung in der Kompilierungs-/Ausführungsphase auftreten, anstatt zur Anweisungskonstruktionszeit. Siehe die unten verlinkten Migrationshinweise für vollständige Details.

  Siehe auch

  Viele Core- und ORM-Anweisungsobjekte führen nun einen Großteil ihrer Konstruktion und Validierung in der Kompilierungsphase durch

• [orm] [change]

  Die automatische Eindeutigkeit von Zeilen auf der Clientseite ist für den neuen 2.0-Stil von ORM-Abfragen deaktiviert. Dies verbessert sowohl Klarheit als auch Leistung. Die Eindeutigkeit von Zeilen auf der Clientseite ist jedoch im Allgemeinen erforderlich, wenn joined eager loading für Collections verwendet wird, da es Duplikate der primären Entität für jedes Element der Collection geben wird, da ein Join verwendet wurde. Diese Eindeutigkeit muss nun manuell aktiviert werden und kann durch den neuen Modifikator Result.unique() erreicht werden. Um stille Fehler zu vermeiden, erfordert die ORM explizit, dass die Methode aufgerufen wird, wenn das Ergebnis einer ORM-Abfrage im 2.0-Stil joined load collections verwendet. Die neuere selectinload()-Strategie ist wahrscheinlich ohnehin für das Eager Loading von Collections vorzuziehen.

  Siehe auch

  ORM-Zeilen werden nicht standardmäßig eindeutig gemacht

  Referenzen: #4395

• [orm] [change]

  Die ORM wird nun warnen, wenn sie aufgefordert wird, eine select()-Konstruktion implizit in eine Unterabfrage zu konvertieren. Dies geschieht in Bereichen wie den Methoden Query.select_entity_from() und Query.select_from() sowie in der Funktion with_polymorphic(). Wenn ein SelectBase (was von select() erzeugt wird) oder ein Query-Objekt direkt an diese und andere Funktionen übergeben wird, konvertiert die ORM diese typischerweise in eine Unterabfrage, indem die Methode SelectBase.alias() automatisch aufgerufen wird (was nun durch die Methode SelectBase.subquery() ersetzt wurde). Siehe die unten verlinkten Migrationshinweise für weitere Details.

  Siehe auch

  Eine SELECT-Anweisung wird nicht mehr implizit als FROM-Klausel betrachtet

  Referenzen: #4617

• [orm] [change]

  Die von Query zurückgegebene Klasse „KeyedTuple“ wird nun durch die Core Row-Klasse ersetzt, die sich genauso verhält wie KeyedTuple. In SQLAlchemy 2.0 geben sowohl Core als auch ORM Ergebniszeilen mit demselben Row-Objekt zurück. In der Zwischenzeit verwendet Core eine Rückwärtskompatibilitätsklasse LegacyRow, die das frühere Mapping/Tuple-Hybridverhalten von „RowProxy“ beibehält.

  Siehe auch

  Das von Query zurückgegebene „KeyedTuple“-Objekt wird durch Row ersetzt

  Referenzen: #4710

• [orm] [performance]

  Die Bulk-Update- und -Delete-Methoden Query.update() und Query.delete() sowie ihre 2.0-Stil-Entsprechungen verwenden nun RETURNING, wenn die „fetch“-Strategie verwendet wird, um die Liste der betroffenen Primärschlüssel-Identitäten abzurufen, anstatt eine separate SELECT-Abfrage auszugeben, wenn das verwendete Backend RETURNING unterstützt. Darüber hinaus werden bei der „fetch“-Strategie in normalen Fällen die Attribute, die aktualisiert wurden, nicht abgelöst, sondern die aktualisierten Werte werden direkt angewendet, auf die gleiche Weise wie die „evaluate“-Strategie, um eine Aktualisierung des Objekts zu vermeiden. Die „evaluate“-Strategie wird auch auf das Ablösen von Attributen zurückfallen, die auf einen SQL-Ausdruck aktualisiert wurden, der in Python nicht auswertbar war.

  Siehe auch

  ORM Bulk Update und Delete verwenden RETURNING für die „fetch“-Strategie, wenn verfügbar

• [orm] [performance] [postgresql]

  Implementierung der Unterstützung für die psycopg2 execute_values()-Erweiterung innerhalb des ORM-Flush-Prozesses durch die Verbesserungen an Core in #5401, sodass diese Erweiterung sowohl als Strategie zum Stapeln von INSERT-Anweisungen als auch zur Abfrage von Primärschlüsselwerten über RETURNING für mehrere Parametersätze verwendet wird. Dies ermöglicht, dass fast alle von der ORM im Auftrag von PostgreSQL ausgegebenen INSERT-Anweisungen in Stapeln und über die execute_values()-Erweiterung übermittelt werden können, was für dieses spezielle Backend fünfmal schneller ist als plain executemany().

  Siehe auch

  ORM Batch-Inserts mit psycopg2 stapeln nun Anweisungen mit RETURNING in den meisten Fällen

  Referenzen: #5263

• [orm] [bug]

  Eine Abfrage, die gegen eine abgebildete Vererbungsunterklasse gerichtet ist und auch Query.select_entity_from() oder eine ähnliche Technik verwendet, um eine vorhandene Unterabfrage zum SELECT daraus bereitzustellen, löst nun einen Fehler aus, wenn die gegebene Unterabfrage Entitäten zurückgibt, die nicht der gegebenen Unterklasse entsprechen, d. h. Geschwister- oder Oberklassen derselben Hierarchie sind. Zuvor wurden diese ohne Fehler zurückgegeben. Darüber hinaus muss die gegebene Unterabfrage bei einer Single-Inheritance-Abbildung die entsprechende Filterung gegen die polymorphe Diskriminatorspalte anwenden, um diesen Fehler zu vermeiden; zuvor fügte die Query diese Kriterien der äußeren Abfrage hinzu, was jedoch einige Arten von Abfragen beeinträchtigt, die auch andere Arten von Entitäten zurückgeben.

  Siehe auch

  Strengeres Verhalten bei Abfragen von Vererbungsabbildungen mit benutzerdefinierten Abfragen

  Referenzen: #5122

• [orm] [bug]

  Die internen Attributsymbole NO_VALUE und NEVER_SET wurden vereinheitlicht, da es keinen bedeutsamen Unterschied zwischen diesen beiden Symbolen gab, abgesehen von einigen Code-Pfaden, bei denen sie auf subtile und undokumentierte Weise unterschieden wurden; diese wurden behoben.

  Referenzen: #4696

• [orm] [bug]

  Fehler behoben, bei dem eine auf einem Mapper gegen eine select()-Konstruktion spezifizierte Versionsspalte, bei der die version_id_col selbst gegen die zugrunde liegende Tabelle gerichtet war, zusätzliche Ladungen verursachte, wenn sie aufgerufen wurde, selbst wenn der Wert lokal durch den Flush persistiert wurde. Die eigentliche Korrektur ist ein Ergebnis der Änderungen in #4617, da ein select()-Objekt kein .c-Attribut mehr hat und daher den Mapper nicht mehr dazu bringt, zu glauben, dass ein unbekannter Spaltenwert vorhanden ist.

  Referenzen: #4194

• [orm] [bug]

  Eine UnmappedInstanceError wird nun für InstrumentedAttribute ausgelöst, wenn eine Instanz ein nicht abgebildetes Objekt ist. Zuvor wurde ein AttributeError ausgelöst. Pull Request von Ramon Williams.

  Referenzen: #3858

• [orm] [bug]

  Das Session-Objekt initiiert keine SessionTransaction-Objekte mehr sofort nach der Erstellung oder nachdem die vorherige Transaktion geschlossen wurde; stattdessen löst die „autobegin“-Logik die neue SessionTransaction bei Bedarf aus, wenn sie als nächstes benötigt wird. Die Gründe dafür sind die Entfernung von Referenzzyklen aus einer geschlossenen Session sowie die Reduzierung des Overhead durch die Erstellung von SessionTransaction-Objekten, die oft sofort verworfen werden. Diese Änderung wirkt sich auf das Verhalten des Hooks SessionEvents.after_transaction_create() aus, da das Ereignis ausgelöst wird, wenn die Session zum ersten Mal eine SessionTransaction benötigt, anstatt jedes Mal, wenn die Session erstellt oder die vorherige SessionTransaction geschlossen wurde. Interaktionen mit der Engine und der Datenbank selbst bleiben unberührt.

  Siehe auch

  Session erhält neues „autobegin“-Verhalten

  Referenzen: #5074

• [orm] [bug]

  Hinzugefügte neue Funktionalitäten zur Entitätszielausrichtung im ORM-Query-Kontext, die Fälle abdecken, in denen die Session ein Bindungs-Dictionary gegen gemappte Klassen verwendet, anstatt einer einzelnen Bindung, und die Query gegen eine Core-Anweisung gerichtet ist, die letztendlich aus einer Methode wie Query.subquery() generiert wurde. Zuerst mithilfe einer Tiefensuche implementiert, nutzt der aktuelle Ansatz die vereinheitlichte select()-Konstruktion, um den ersten Mapper zu verfolgen, der Teil der Konstruktion ist.

  Referenzen: #4829

• [orm] [bug] [inheritance]

  Es wird nun ein ArgumentError ausgelöst, wenn sowohl die Parameter selectable als auch flat in with_polymorphic() auf True gesetzt sind. Der Name des Selectable ist bereits aliasiert und das Anwenden von flat=True überschreibt den Namen des Selectable mit einem anonymen Namen, was zuvor zu einem Fehler im Code geführt hätte. Pull Request von Ramon Williams.

  Referenzen: #4212

• [orm] [bug]

  Problem in den internen Polymorphic-Loading-Mechanismen behoben, das in bestimmten "Unexpiration"-Szenarien in Verbindung mit der Verwendung von "with_polymorphic" auf eine teurere, bald als veraltet geltende Form der Ergebnisspalten-Suche zurückfiel.

  Referenzen: #4718

• [orm] [bug]

  Es wird ein Fehler ausgelöst, wenn irgendwelche persistenzbezogenen "cascade"-Einstellungen für eine relationship() vorgenommen werden, die auch viewonly=True setzt. Die "cascade"-Einstellungen sind nun standardmäßig nur nicht-persistenzbezogen, wenn viewonly ebenfalls gesetzt ist. Dies ist die Fortsetzung von #4993, wo diese Einstellung in 1.3 geändert wurde, um eine Warnung auszugeben.

  Siehe auch

  Persistenzbezogene Cascade-Operationen mit viewonly=True nicht erlaubt

  Referenzen: #4994

• [orm] [bug]

  Die Deklarative Vererbungsprüfung wurde verbessert, um nicht fehzuschlagen, wenn dieselbe Basisklasse mehrmals in der Basisvererbungsliste vorkommt.

  Referenzen: #4699

• [orm] [bug]

  Fehler in der ORM-Versionierungsfunktion behoben, bei der die Zuweisung einer expliziten version_id für einen Zähler, der gegen eine gemappte auswählbare Konfiguration mit version_id_col gegen die zugrunde liegende Tabelle konfiguriert wurde, fehlschlagen würde, wenn der vorherige Wert abgelaufen wäre; dies lag daran, dass das gemappte Attribut nicht mit active_history=True konfiguriert worden wäre.

  Referenzen: #4195

• [orm] [bug]

  Es wird nun eine Ausnahme ausgelöst, wenn die ORM eine Zeile für eine polymorphe Instanz lädt, die einen Primärschlüssel hat, aber die Diskriminatorspalte NULL ist, da Diskriminatorspalten nicht NULL sein sollten.

  Referenzen: #4836

• [orm] [bug]

  Der Zugriff auf ein sammlungsbezogenes Attribut eines neu erstellten Objekts verändert nun nicht mehr __dict__, gibt aber weiterhin eine leere Sammlung zurück, wie es schon immer der Fall war. Dies ermöglicht eine konsistente Funktionsweise von sammlungsbezogenen Attributen im Vergleich zu Skalarattributen, die None zurückgeben, aber auch __dict__ nicht verändern. Um die Veränderung der Sammlung zu ermöglichen, wird dieselbe leere Sammlung jedes Mal zurückgegeben, nachdem sie anfänglich erstellt wurde, und wenn sie verändert wird (z. B. ein Element angefügt, hinzugefügt usw.), wird sie in __dict__ verschoben. Dies beseitigt die letzten schreibgeschützten Lesezugriffs-Nebenwirkungen im ORM.

  Siehe auch

  Der Zugriff auf ein nicht initialisiertes Sammlungsattribut eines transienten Objekts verändert __dict__ nicht mehr

  Referenzen: #4519

• [orm] [bug]

  Das erneute Laden eines abgelaufenen Objekts löst nun ein Autoflush aus, wenn die Liste der abgelaufenen Attribute ein oder mehrere Attribute enthält, die explizit abgelaufen oder mit den Methoden Session.expire() oder Session.refresh() neu geladen wurden. Dies ist ein Versuch, einen Mittelweg zwischen dem normalen Ablauf von Attributen, der in vielen Fällen auftreten kann, in denen Autoflush nicht erwünscht ist, und dem Fall, in dem Attribute explizit ablaufen oder neu geladen werden und diese Attribute möglicherweise von anderen ausstehenden Zuständen in der Sitzung abhängen, die geleert werden müssen. Die beiden Methoden erhalten nun auch ein neues Flag Session.expire.autoflush und Session.refresh.autoflush, standardmäßig True; wenn sie auf False gesetzt sind, wird der auf den Ablauf für diese Attribute angewendete Autoflush deaktiviert.

  Referenzen: #5226

• [orm] [bug]

  Das Verhalten des Flags relationship.cascade_backrefs wird in 2.0 umgekehrt und bedingungslos auf False gesetzt, sodass Backrefs keine Save-Update-Operationen von einer Vorwärtszuweisung zu einer Rückwärtszuweisung weitergeben. Eine Deprecation-Warnung für 2.0 wird ausgegeben, wenn der Parameter beim Auftreten einer solchen Kaskadenoperation auf seinem Standardwert True belassen wird. Das neue Verhalten kann immer durch Setzen des Flags auf False für eine bestimmte relationship() etabliert werden, oder allgemeiner durch Setzen des Flags Session.future auf True.

  Siehe auch

  Verhalten von cascade_backrefs für die Entfernung in 2.0 als veraltet markiert

  Referenzen: #5150

• [orm] [deprecated]

  Die "Slice Index"-Funktion, die von Query sowie vom dynamischen Relationship-Loader verwendet wird, wird in SQLAlchemy 2.0 keine negativen Indizes mehr akzeptieren. Diese Operationen funktionieren nicht effizient und laden die gesamte Sammlung, was sowohl überraschend als auch unerwünscht ist. Diese werden in 1.4 eine Warnung ausgeben, es sei denn, das Flag Session.future ist gesetzt, in welchem Fall ein IndexError ausgelöst wird.

  Referenzen: #5606

• [orm] [deprecated]

  Der Aufruf der Methode Query.instances() ohne Übergabe eines QueryContext ist veraltet. Der ursprüngliche Anwendungsfall dafür war, dass eine Query ORM-Objekte liefern konnte, wenn ihr nur die auszuwählenden Entitäten sowie ein DBAPI-Cursor-Objekt übergeben wurden. Damit dies jedoch korrekt funktioniert, sind wesentliche Metadaten erforderlich, die von einem SQLAlchemy ResultProxy übergeben werden, der aus den gemappten Spaltenausdrücken abgeleitet wird und ursprünglich aus dem QueryContext stammt. Um ORM-Ergebnisse aus beliebigen SELECT-Anweisungen abzurufen, sollte die Methode Query.from_statement() verwendet werden.

  Referenzen: #4719

• [orm] [deprecated]

  Die Verwendung von Strings zur Darstellung von Relationship-Namen in ORM-Operationen wie Query.join(), sowie Strings für alle ORM-Attributnamen in Loader-Optionen wie selectinload() ist veraltet und wird in SQLAlchemy 2.0 entfernt. Das klassengebundene Attribut sollte stattdessen übergeben werden. Dies bietet eine wesentlich bessere Spezifität für die gegebene Methode, ermöglicht Modifikatoren wie of_type() und reduziert die interne Komplexität.

  Zusätzlich sind die Parameter aliased und from_joinpoint für Query.join() ebenfalls veraltet. Die aliased()-Konstruktion bietet nun eine große Flexibilität und Leistungsfähigkeit und sollte direkt verwendet werden.

  Siehe auch

  ORM Query - Joins / Laden von Relationships verwendet Attribute, nicht Strings

  ORM Query - join(…, aliased=True), from_joinpoint entfernt

  Referenzen: #4705, #5202

• [orm] [deprecated]

  Die Logik in Query.distinct(), die Spalten in der ORDER BY-Klausel automatisch zur Spaltenklausel hinzufügt, wurde als veraltet markiert und wird in 2.0 entfernt.

  Siehe auch

  DISTINCT mit zusätzlichen Spalten verwenden, aber nur die Entität auswählen

  Referenzen: #5134

• [orm] [deprecated]

  Die Übergabe von Schlüsselwortargumenten an Methoden wie Session.execute(), die an die Methode Session.get_bind() übergeben werden sollen, ist veraltet. Stattdessen sollte das neue Dictionary Session.execute.bind_arguments übergeben werden.

  Referenzen: #5573

• [orm] [deprecated]

  Die Funktionen eagerload() und relation() waren alte Aliase und sind nun veraltet. Verwenden Sie stattdessen joinedload() bzw. relationship().

  Referenzen: #5192

• [orm] [removed]

  Alle seit langem veralteten "Erweiterungs"-Klassen wurden entfernt, einschließlich MapperExtension, SessionExtension, PoolListener, ConnectionProxy, AttributeExtension. Diese Klassen sind seit Version 0.7 veraltet und wurden lange vom Event-Listener-System abgelöst.

  Referenzen: #4638

• [orm] [removed]

  Entfernen der veralteten Loader-Optionen joinedload_all, subqueryload_all, lazyload_all, selectinload_all. An ihrer Stelle sollte die normale Version mit Methodenkettung verwendet werden.

  Referenzen: #4642

• [orm] [removed]

  Entfernen der veralteten Funktion comparable_property. Bitte beachten Sie die hybrid-Erweiterung. Dies entfernt auch die Funktion comparable_using in der deklarativen Erweiterung.

  Entfernen der veralteten Funktion compile_mappers. Bitte verwenden Sie configure_mappers()

  Entfernen der veralteten Methode collection.linker. Bitte beachten Sie die Event-Handler AttributeEvents.init_collection() und AttributeEvents.dispose_collection().

  Entfernen der veralteten Methode Session.prune und des Parameters Session.weak_identity_map. Siehe das Rezept unter Session Referencing Behavior für einen ereignisbasierten Ansatz zur Aufrechterhaltung starker Identitätsreferenzen. Diese Änderung entfernt auch die Klasse StrongInstanceDict.

  Entfernen des veralteten Parameters mapper.order_by. Verwenden Sie Query.order_by(), um die Reihenfolge eines Ergebnissatzes zu bestimmen.

  Entfernen des veralteten Parameters Session._enable_transaction_accounting.

  Entfernen des veralteten Parameters Session.is_modified.passive.

  Referenzen: #4643

engine

• [engine] [feature]

  Ein komplett neues Result-Objekt wurde implementiert, das das vorherige ResultProxy-Objekt ersetzt. Wie in Core implementiert, verfügt die Unterklasse CursorResult über eine kompatible Aufrufschnittstelle mit dem vorherigen ResultProxy und fügt zusätzlich eine große Menge neuer Funktionalitäten hinzu, die sowohl auf Core-Ergebnismengen als auch auf ORM-Ergebnismengen angewendet werden können, die nun in dasselbe Modell integriert sind. Result beinhaltet Funktionen wie Spaltenauswahl und -neuordnung, verbesserte fetchmany-Muster, Uniquing sowie eine Vielzahl von Implementierungen, die auch zur Erstellung von Datenbankergebnissen aus In-Memory-Strukturen verwendet werden können.

  Siehe auch

  Neues Ergebnisobjekt

  Referenzen: #4395, #4959, #5087

• [engine] [feature] [orm]

  SQLAlchemy enthält nun Unterstützung für Python asyncio sowohl in Core als auch in ORM, über die enthaltene asyncio-Erweiterung. Die Erweiterung nutzt die greenlet-Bibliothek, um die synchron ausgerichteten Interna von SQLAlchemy anzupassen, sodass eine asyncio-Schnittstelle, die letztendlich mit einem asyncio-Datenbankadapter interagiert, nun möglich ist. Derzeit wird nur der asyncpg-Treiber für PostgreSQL unterstützt.

  Siehe auch

  Unterstützung für asynchrones E/A für Core und ORM

  Referenzen: #3414

• [engine] [feature] [alchemy2]

  Implementierung des Parameters create_engine.future, der die Vorwärtskompatibilität mit SQLAlchemy 2 ermöglicht. Dieser wird für die Vorwärtskompatibilität mit SQLAlchemy 2 verwendet. Diese Engine bietet stets transaktionales Verhalten mit Autobegin.

  Siehe auch

  SQLAlchemy 2.0 - Major Migration Guide

  Referenzen: #4644

• [engine] [feature] [pyodbc]

  Die "setinputsizes()" Dialekthaken wurden überarbeitet, um für jeden beliebigen DBAPI korrekt erweiterbar zu sein, indem Dialekten individuelle Haken ermöglicht werden, die cursor.setinputsizes() im entsprechenden Stil für diesen DBAPI aufrufen können. Insbesondere ist dies für die Verwendung im Stil von pyodbc gedacht, die sich grundlegend von der von cx_Oracle unterscheidet. Unterstützung für pyodbc wurde hinzugefügt.

  Referenzen: #5649

• [engine] [feature]

  Neue Reflektionsmethoden Inspector.get_sequence_names(), die alle definierten Sequenzen zurückgibt, und Inspector.has_sequence(), um zu prüfen, ob eine bestimmte Sequenz existiert, wurden hinzugefügt. Unterstützung für diese Methoden wurde zu den Backends hinzugefügt, die Sequence unterstützen: PostgreSQL, Oracle und MariaDB >= 10.3.

  Referenzen: #2056

• [engine] [feature]

  Der Parameter Table.autoload_with akzeptiert nun direkt ein Inspector-Objekt, ebenso wie jede Engine oder Connection, wie es zuvor der Fall war.

  Referenzen: #4755

• [engine] [change]

  Die Klasse RowProxy ist keine "Proxy"-Objekt mehr, sondern wird direkt mit den nachbearbeiteten Inhalten der DBAPI-Zeilentupel bei der Erstellung gefüllt. Die nun Row genannte Klasse verhält sich nun eher wie ein benanntes Tupel und die Verarbeitung von Python-Wertprozessoren wurde vereinfacht. Das von ResultProxy zurückgegebene Objekt ist nun die Unterklasse LegacyRow, die weiterhin das Hybridverhalten für Mapping/Tupel beibehält.

  Siehe auch

  RowProxy ist kein "Proxy" mehr; heißt jetzt Row und verhält sich wie ein erweitertes benanntes Tupel.

  Referenzen: #4710

• [engine] [change] [performance] [py3k]

  Die Prüfung "unicode returns", die beim Start des Dialekts unter Python 3 ausgeführt wird und seit vielen Jahren durchgeführt wurde, um das Verhalten des aktuellen DBAPI zu testen, ob es Python Unicode- oder Py2K-Strings für VARCHAR- und NVARCHAR-Datentypen zurückgibt, wurde deaktiviert. Die Prüfung findet standardmäßig weiterhin unter Python 2 statt, jedoch wird der Mechanismus zum Testen des Verhaltens in SQLAlchemy 2.0 entfernt, wenn auch die Unterstützung für Python 2 entfernt wird.

  Diese Logik war sehr effektiv, als sie benötigt wurde, aber da Python 3 nun Standard ist, wird von allen DBAPIs erwartet, dass sie Python 3-Strings für Zeichendatentypen zurückgeben. Für den unwahrscheinlichen Fall, dass ein DBAPI eines Drittanbieters dies nicht unterstützt, ist die Konvertierungslogik innerhalb von String weiterhin verfügbar, und der Dialekt eines Drittanbieters kann dies in seinen anfänglichen Dialekt-Flags angeben, indem er das Dialekt-Flag returns_unicode_strings auf String.RETURNS_CONDITIONAL oder String.RETURNS_BYTES setzt, was beide die Unicode-Konvertierung auch unter Python 3 aktivieren.

  Referenzen: #5315

• [engine] [performance]

  Das Pool-Feature "Pre-Ping" wurde verfeinert, um es nicht für eine DBAPI-Verbindung aufzurufen, die gerade im selben Checkout-Vorgang geöffnet wurde. Pre-Ping gilt nur für eine DBAPI-Verbindung, die in den Pool eingecheckt wurde und wieder ausgecheckt wird.

  Referenzen: #4524

• [engine] [bug]

  Die Funktion Connection.execution_options.schema_translate_map wurde überarbeitet, sodass die Verarbeitung der SQL-Anweisung zur Aufnahme eines spezifischen Schemanamens in der Ausführungsphase der Anweisung erfolgt, anstatt in der Kompilierungsphase. Dies dient der effizienten Zwischenspeicherung der Anweisung. Zuvor wurde das aktuelle Schema, das für einen bestimmten Lauf in die Anweisung gerendert wurde, selbst als Teil des Cache-Schlüssels betrachtet, was bedeutete, dass bei einem Lauf gegen Hunderte von Schemata Hunderte von Cache-Schlüsseln existierten, was den Cache erheblich weniger performant machte. Das neue Verhalten besteht darin, dass das Rendern ähnlich wie beim "Post-Compile"-Rendern, das in 1.4 als Teil von #4645, #4808 hinzugefügt wurde, erfolgt.

  Referenzen: #5004

• [engine] [bug]

  Das Connection-Objekt löscht eine zurückgerollte Transaktion nun nicht mehr, bis die äußerste Transaktion explizit zurückgerollt ist. Dies ist im Wesentlichen dasselbe Verhalten, das die ORM Session seit langem aufweist, bei dem ein expliziter Aufruf von .rollback() auf allen umschließenden Transaktionen erforderlich ist, damit die Transaktion logisch gelöscht wird, auch wenn die DBAPI-Transaktion bereits zurückgerollt wurde. Das neue Verhalten hilft bei Situationen wie dem "ORM-Rollback-Testsuite"-Muster, bei dem die Testsuite die Transaktion innerhalb des ORM-Bereichs zurückrollt, aber das Test-Harness, das den Transaktionsbereich extern kontrollieren möchte, nicht erwartet, dass eine neue Transaktion implizit gestartet wird.

  Siehe auch

  Transaktionen auf Connection-Ebene können nun basierend auf Subtransaktionen inaktiv sein

  Referenzen: #4712

• [engine] [bug]

  Der Dialektinitialisierungsprozess wurde so angepasst, dass die Dialect.on_connect() beim ersten Verbindungsaufbau nicht ein zweites Mal aufgerufen wird. Der Hook wird zuerst aufgerufen, dann wird Dialect.initialize() aufgerufen, falls diese Verbindung die erste für diesen Dialekt ist, und danach werden keine weiteren Events ausgelöst. Dies eliminiert die doppelten Aufrufe der „on_connect“-Funktion, die zu sehr schwierigen Debugging-Situationen führen können.

  Referenzen: #5497

• [engine] [deprecated]

  Das URL-Objekt ist nun ein unveränderliches benanntes Tupel. Um ein URL-Objekt zu ändern, verwenden Sie die Methode URL.set(), um ein neues URL-Objekt zu erzeugen.

  Siehe auch

  Das URL-Objekt ist nun unveränderlich - Hinweise zur Migration

  Referenzen: #5526

• [engine] [deprecated]

  Das Argument MetaData.bind sowie das allgemeine Konzept des „gebundenen Metadaten“ sind in SQLAlchemy 1.4 veraltet und werden in SQLAlchemy 2.0 entfernt. Das Parameter sowie zugehörige Funktionen geben nun eine RemovedIn20Warning aus, wenn Der Veraltungsmodus für SQLAlchemy 2.0 verwendet wird.

  Siehe auch

  „Implizite“ und „verbindunglose“ Ausführung, „gebundene Metadaten“ entfernt

  Referenzen: #4634

• [engine] [deprecated]

  Der Engine-weite Parameter server_side_cursors ist veraltet und wird in einer zukünftigen Version entfernt. Für ungepufferte Cursor sollte die Ausführungsoption Connection.execution_options.stream_results pro Ausführung verwendet werden.

• [engine] [deprecated]

  Die Methode Connection.connect() ist veraltet, ebenso wie das Konzept der „Verzweigung von Verbindungen“, bei dem eine Connection in eine neue kopiert wird, die eine No-Op-Methode „.close()“ hat. Dieses Muster ist auf das Konzept der „verbindungslosen Ausführung“ ausgerichtet, das ebenfalls in 2.0 entfernt wird.

  Referenzen: #5131

• [engine] [deprecated]

  Das Flag case_sensitive in create_engine() ist veraltet; dieses Flag war Teil der Übergangsphase des Ergebniszeilenobjekts, um die Groß-/Kleinschreibungsempfindlichkeit der Spaltenzuordnung als Standard zu ermöglichen und gleichzeitig die Abwärtskompatibilität für die frühere Zuordnungsmethode zu gewährleisten. Auf alle Zeichenkettenzugriffe für eine Zeile sollte so zugegriffen werden, als ob sie groß-/kleinschreibungsempfindlich wären, wie bei jeder anderen Python-Zuordnung auch.

  Referenzen: #4878

• [engine] [deprecated]

  Das „implizite Autocommit“, d. h. das COMMIT, das auftritt, wenn eine DML- oder DDL-Anweisung über eine Verbindung ausgegeben wird, ist veraltet und wird nicht Teil von SQLAlchemy 2.0 sein. Eine Warnung im Stil von 2.0 wird ausgegeben, wenn Autocommit wirksam wird, damit der aufrufende Code angepasst werden kann, um eine explizite Transaktion zu verwenden.

  Als Teil dieser Änderung werden DDL-Methoden wie MetaData.create_all(), wenn sie gegen eine Engine verwendet werden, die Operation in einem BEGIN-Block ausführen, falls noch keiner gestartet wurde.

  Siehe auch

  SQLAlchemy 2.0 Deprecations Mode

  Referenzen: #4846

• [engine] [deprecated]

  Das Verhalten, bei dem eine Column als Schlüssel in einer Ergebniszeilensuche verwendet werden kann, wenn diese Column nicht Teil des ausgewählten SQL-Auswahlverfahrens ist, d. h. nur nach Namen zugeordnet wird, wurde veraltet. In diesem Fall wird nun eine Veraltungswarnung ausgegeben. Verschiedene ORM-Anwendungsfälle, wie z. B. solche, die text()-Konstrukte betreffen, wurden verbessert, sodass diese Fallback-Logik in den meisten Fällen vermieden wird.

  Referenzen: #4877

• [engine] [deprecated]

  Die verbleibenden Introspektions- und Hilfsmethoden auf Engine-Ebene, einschließlich Engine.run_callable(), Engine.transaction(), Engine.table_names(), Engine.has_table(), sind veraltet. Die Hilfsmethoden werden durch moderne Kontextmanager-Muster ersetzt, und die Tabellenintrospektionsaufgaben werden durch das Inspector-Objekt abgedeckt.

  Referenzen: #4755

• [engine] [removed]

  Entfernung der veralteten Methode get_primary_keys in den Klassen Dialect und Inspector. Bitte beziehen Sie sich auf die Methoden Dialect.get_pk_constraint() und Inspector.get_primary_keys().

  Entfernung des veralteten Events dbapi_error und der Methode ConnectionEvents.dbapi_error. Bitte beziehen Sie sich auf den Event ConnectionEvents.handle_error(). Diese Änderung entfernt auch die Attribute ExecutionContext.is_disconnect und ExecutionContext.exception.

  Referenzen: #4643

• [engine] [removed]

  Die interne Dialektmethode Dialect.reflecttable wurde entfernt. Eine Überprüfung von Drittanbieter-Dialekten hat keine Verwendung dieser Methode ergeben, da sie bereits als eine dokumentiert war, die von externen Dialekten nicht verwendet werden sollte. Darüber hinaus wurde die private Methode Engine._run_visitor ebenfalls entfernt.

  Referenzen: #4755

• [engine] [removed]

  Der lange veraltete Parameter Inspector.get_table_names.order_by wurde entfernt.

  Referenzen: #4755

• [engine] [renamed]

  Die Methode Inspector.reflecttable() wurde in Inspector.reflect_table() umbenannt.

  Referenzen: #5244

sql

• [sql] [feature]

  Als integrierte Funktion wurde dem SQL-Compiler die „FROM-Linting“-Funktion hinzugefügt. Diese ermöglicht es dem Compiler, ein Diagramm aller FROM-Klauseln in einer bestimmten SELECT-Anweisung zu verwalten, die durch Kriterien in der WHERE- oder JOIN-Klausel miteinander verbunden sind. Wenn zwei FROM-Klauseln keinen Pfad zwischen sich haben, wird eine Warnung ausgegeben, dass die Abfrage möglicherweise ein kartesisches Produkt erzeugt. Da die Core Expression Language sowie die ORM auf einem Modell der „impliziten FROMs“ basieren, bei dem eine bestimmte FROM-Klausel automatisch hinzugefügt wird, wenn ein Teil der Abfrage darauf verweist, ist es leicht, dass dies unbeabsichtigt geschieht, und es wird gehofft, dass die neue Funktion bei diesem Problem hilft.

  Siehe auch

  Die integrierte FROM-Linting-Funktion warnt vor möglichen kartesischen Produkten in einer SELECT-Anweisung

  Referenzen: #4737

• [sql] [feature] [mssql] [oracle]

  Neue Funktion „Post-Compile-Parameter“ hinzugefügt. Diese Funktion ermöglicht es, dass ein bindparam()-Konstrukt seinen Wert vor der Übergabe an den DBAPI-Treiber in die SQL-Zeichenkette rendern lässt, aber nach dem Kompilierungsschritt, unter Verwendung der Funktion „Literal Rendering“ des Compilers. Der unmittelbare Grund für diese Funktion ist die Unterstützung von LIMIT/OFFSET-Schemata, die mit gebundenen Parametern, die vom Datenbanktreiber behandelt werden, nicht funktionieren oder schlecht performen, während sie gleichzeitig zulassen, dass SQLAlchemy SQL-Konstrukte in ihrer kompilierten Form cachbar sind. Die unmittelbaren Ziele der neuen Funktion sind die „TOP N“-Klausel, die von SQL Server (und Sybase) verwendet wird und keinen gebundenen Parameter unterstützt, sowie die „ROWNUM“- und optionalen „FIRST_ROWS()“-Schemata, die vom Oracle-Dialekt verwendet werden, von denen ersteres bekanntermaßen ohne gebundene Parameter besser performt und letzteres keinen gebundenen Parameter unterstützt. Die Funktion baut auf den Mechanismen auf, die zuerst zur Unterstützung von „expanding“ Parametern für IN-Ausdrücke entwickelt wurden. Als Teil dieser Funktion wird die Oracle-Funktion use_binds_for_limits bedingungslos eingeschaltet und dieses Flag ist nun veraltet.

  Siehe auch

  Neue "Post-Compile"-gebundene Parameter für LIMIT/OFFSET in Oracle, SQL Server

  Referenzen: #4808

• [sql] [feature]

  Reguläre Ausdrücke auf unterstützten Backends hinzugefügt. Zwei Operationen wurden definiert

  • ColumnOperators.regexp_match(), die eine funktionähnliche Funktion für reguläre Ausdrücke implementiert.

  • ColumnOperators.regexp_replace(), die eine Funktion zum Ersetzen von Zeichenketten mittels regulärer Ausdrücke implementiert.

  Zu den unterstützten Backends gehören SQLite, PostgreSQL, MySQL / MariaDB und Oracle.

  Siehe auch

  Unterstützung für SQL-Reguläre-Ausdruck-Operatoren

  Referenzen: #1390

• [sql] [feature]

  Der select()-Konstrukt und verwandte Konstrukte erlauben nun die Duplizierung von Spaltenbezeichnungen und Spalten selbst in der Spaltenklausel, was genau widerspiegelt, wie Spaltenausdrücke übergeben wurden. Dies ermöglicht, dass die von einem ausgeführten Ergebnis zurückgegebenen Tupel mit dem übereinstimmen, was ursprünglich ausgewählt wurde, was der Funktionsweise von ORM Query entspricht. Dies stellt somit eine bessere Kompatibilität zwischen den beiden Konstrukten her. Zusätzlich ermöglicht es spaltenpositionsabhängigen Strukturen wie UNIONs (z. B. _selectable.CompoundSelect) intuitiver konstruiert zu werden, in Fällen, in denen eine bestimmte Spalte mehrfach vorkommen kann. Um diese Änderung zu unterstützen, wurde die ColumnCollection überarbeitet, um Duplikate von Spalten zu unterstützen und den Zugriff über Ganzzahlindizes zu ermöglichen.

  Siehe auch

  SELECT-Objekte und abgeleitete FROM-Klauseln erlauben doppelte Spalten und Spaltenbezeichnungen

  Referenzen: #4753

• [sql] [feature]

  Die Funktion zur Unterscheidung von Bezeichnungen im select()-Konstrukt wurde erweitert, so dass bei Verwendung einer Select-Anweisung in einer Subquery, wiederholte Spaltennamen aus verschiedenen Tabellen nun automatisch mit einem eindeutigen Namen gekennzeichnet werden, ohne dass die volle Funktion „apply_labels()“ erforderlich ist, die Tabellenname plus Spaltenname kombiniert. Die eindeutigen Bezeichnungen sind als einfache Zeichenketten-Schlüssel im .c-Attribut der Subquery verfügbar, und am wichtigsten ist, dass die Funktion es ermöglicht, dass ein ORM aliased()-Konstrukt gegen die Kombination aus einer Entität und einer beliebigen Subquery korrekt funktioniert, wobei die richtigen Spalten trotz gleichnamiger Spalten in den Quelltabellen angesprochen werden, ohne dass eine Warnung „apply labels“ erforderlich ist.

  Siehe auch

  Auswahl aus der Abfrage selbst als Subquery, z.B. „from_self()“ - Veranschaulicht die neue Unterscheidungsfunktion als Teil einer Strategie zur Migration von der Methode Query.from_self().

  Referenzen: #5221

• [sql] [feature]

  Die Funktion „expanding IN“, die IN-Ausdrücke zur Ausführungszeit von Abfragen generiert, die auf den spezifischen Parametern der Anweisung basieren, wird nun für alle IN-Ausdrücke verwendet, die gegen Listen von Literalwerten ausgeführt werden. Dies ermöglicht, dass IN-Ausdrücke vollständig und unabhängig von der übergebenen Werte Liste cachbar sind und schließt auch die Unterstützung für leere Listen ein. Für Szenarien, in denen der IN-Ausdruck nicht-literale SQL-Ausdrücke enthält, bleibt das alte Verhalten der Vorab-Rendering für jede Position in der IN-Klausel erhalten. Die Änderung vervollständigt auch die Unterstützung für das Ausdehnen von IN mit Tupeln, wo bisher typspezifische Bind-Prozessoren nicht wirksam wurden.

  Siehe auch

  Alle IN-Ausdrücke rendern Parameter für jeden Wert in der Liste dynamisch (z.B. expandierende Parameter)

  Referenzen: #4645

• [sql] [feature]

  Zusammen mit der neuen transparenten Statement-Caching-Funktion, die im Rahmen von #4369 eingeführt wurde, wird eine neue Funktion hinzugefügt, die darauf abzielt, den Python-Overhead bei der Erstellung von Anweisungen zu reduzieren. Diese Funktion ermöglicht die Verwendung von Lambdas zur Angabe von Argumenten, die an ein Anweisungsobjekt wie select(), Query(), update() usw. übergeben werden, sowie die Konstruktion vollständiger Anweisungen innerhalb von Lambdas, ähnlich wie im „Baked Query“-System. Die Begründung für die Verwendung von Lambdas ist an die des „Baked Query“-Ansatzes angepasst, der Lambdas verwendet, um beliebige Python-Codeblöcke in ein Callable zu kapseln, das nur aufgerufen werden muss, wenn die Anweisung zum ersten Mal in eine Zeichenkette umgewandelt wird. Die neue Funktion ist jedoch ausgefeilter, da Python-Literalwerte, die als Parameter übergeben würden, automatisch extrahiert werden, sodass die Verwendung von bindparam()-Objekten mit solchen Abfragen nicht mehr erforderlich ist. Die Nutzung der Funktion ist optional und kann in einem beliebigen Umfang genutzt werden, solange die Anweisungen vollständig cachbar bleiben.

  Siehe auch

  Verwendung von Lambdas zur Erzielung erheblicher Geschwindigkeitssteigerungen bei der Anweisungsproduktion

  Referenzen: #5380

• [sql] [usecase]

  Die Methoden Index.create() und Index.drop() verfügen nun über einen Parameter Index.create.checkfirst, ähnlich wie bei Table und Sequence. Wenn dieser aktiviert ist, erkennt die Operation, ob der Index vorhanden ist (oder nicht), bevor eine Erstellungs- oder Löschoperation durchgeführt wird.

  Referenzen: #527

• [sql] [usecase]

  Die Operatoren true() und false() können nun als „onclause“ eines join() auf einem Backend, das keine „native booleschen“ Ausdrücke unterstützt (z. B. Oracle oder SQL Server), angewendet werden, und der Ausdruck wird als „1=1“ für wahr und „1=0“ für falsch gerendert. Dies ist das Verhalten, das vor vielen Jahren in #2804 für und/oder Ausdrücke eingeführt wurde.

• [sql] [usecase]

  Änderung der Methode __str von ColumnCollection, um Verwechslungen mit einer Python-Liste von Zeichenketten zu vermeiden.

  Referenzen: #5191

• [sql] [usecase]

  Unterstützung für FETCH {FIRST | NEXT} [ count ] {ROW | ROWS} {ONLY | WITH TIES} in der Auswahl für die unterstützten Backends, derzeit PostgreSQL, Oracle und MSSQL, hinzugefügt.

  Referenzen: #5576

• [sql] [usecase]

  Zusätzliche Logik wurde hinzugefügt, so dass bestimmte SQL-Ausdrücke, die typischerweise eine einzelne Datenbankspalte umschließen, den Namen dieser Spalte als ihre „anonyme Bezeichnung“ in einer SELECT-Anweisung verwenden. Dies kann die schlüsselbasierte Suche in Ergebnis-Tupeln intuitiver machen. Das Hauptbeispiel hierfür ist ein CAST-Ausdruck, z.B. CAST(table.colname AS INTEGER), der seinen Standardnamen als „colname“ exportiert, anstatt des üblichen „anon_1“-Labels, d.h. CAST(table.colname AS INTEGER) AS colname. Wenn der innere Ausdruck keinen Namen hat, wird die vorherige Logik für „anonyme Bezeichnungen“ verwendet. Bei der Verwendung von SELECT-Anweisungen, die Select.apply_labels() verwenden, wie sie vom ORM ausgegeben werden, erzeugt die Bezeichnungslogik <tablename>_<inner column name>, auf dieselbe Weise, als wäre die Spalte allein benannt. Die Logik gilt derzeit für die Konstrukte cast() und type_coerce() sowie für einige einteilige boolesche Ausdrücke.

  Siehe auch

  Verbesserte Spaltenbenennung für einfache Spaltenausdrücke mit CAST oder ähnlichem

  Referenzen: #4449

• [sql] [change]

  Das „Clause Coercion“-System, das das System von SQLAlchemy Core zum Empfangen von Argumenten und deren Auflösung in ClauseElement-Strukturen zum Aufbau von SQL-Ausdrucksobjekten, wurde von einer Reihe von Ad-hoc-Funktionen zu einem vollständig konsistenten klassenbasierten System umgeschrieben. Diese Änderung ist intern und sollte keine Auswirkungen auf Endbenutzer haben, abgesehen von spezifischeren Fehlermeldungen, wenn der falsche Argumenttyp an ein Ausdrucksobjekt übergeben wird. Die Änderung ist jedoch Teil einer größeren Reihe von Änderungen, die die Rolle und das Verhalten von select()-Objekten betreffen.

  Referenzen: #4617

• [sql] [change]

  Ein Kernobjekt Values wurde hinzugefügt, das es ermöglicht, ein VALUES-Konstrukt in der FROM-Klausel einer SQL-Anweisung für Datenbanken zu verwenden, die dies unterstützen (hauptsächlich PostgreSQL und SQL Server).

  Referenzen: #4868

• [sql] [change]

  Der select()-Konstrukt bewegt sich hin zu einer neuen Aufrufform, die select(col1, col2, col3, ..) lautet, wobei alle anderen Schlüsselwortargumente entfernt wurden, da diese alle über generative Methoden abgedeckt werden. Die einzelne Liste von Spalten- oder Tabellenargumenten, die an select() übergeben wird, wird weiterhin akzeptiert, ist aber nicht mehr erforderlich, wenn Ausdrücke in einem einfachen Positionsstil übergeben werden. Andere Schlüsselwortargumente sind bei Verwendung dieser Form nicht zulässig.

  Siehe auch

  select(), case() akzeptieren nun positionelle Ausdrücke

  Referenzen: #5284

• [sql] [change]

  Als Teil des SQLAlchemy 2.0 Migrationsprojekts wurde eine konzeptionelle Änderung an der Rolle der SelectBase-Klassenhierarchie, die die Wurzel aller „SELECT“-Anweisungskonstrukte ist, vorgenommen, sodass diese nicht mehr direkt als FROM-Klauseln dienen, d. h. sie erben nicht mehr von FromClause. Für Endbenutzer bedeutet die Änderung hauptsächlich, dass jede Platzierung eines select()-Konstrukts in der FROM-Klausel eines anderen select() zunächst erfordert, dass es in eine Subquery eingekapselt wird, was historisch durch die Verwendung der Methode SelectBase.alias() geschieht und nun auch durch die Verwendung von SelectBase.subquery() möglich ist. Dies war in jedem Fall oft eine Anforderung, da viele Datenbanken unbenannte SELECT-Subqueries in ihrer FROM-Klausel ohnehin nicht akzeptieren.

  Siehe auch

  Eine SELECT-Anweisung wird nicht mehr implizit als FROM-Klausel betrachtet

  Referenzen: #4617

• [sql] [change]

  Eine neue Kernklasse Subquery wurde hinzugefügt, die an die Stelle von Alias bei der Erstellung benannter Subqueries aus einem SelectBase-Objekt tritt. Subquery verhält sich genauso wie Alias und wird aus der Methode SelectBase.subquery() erzeugt; zur einfachen Nutzung und Abwärtskompatibilität ist die Methode SelectBase.alias() synonym mit dieser neuen Methode.

  Siehe auch

  Eine SELECT-Anweisung wird nicht mehr implizit als FROM-Klausel betrachtet

  Referenzen: #4617

• [sql] [performance]

  Eine umfassende Reorganisation und Refactoring der internen Core- und ORM-Komponenten ermöglicht es nun, dass alle Core- und ORM-Anweisungen im Bereich DQL (z. B. SELECTs) und DML (z. B. INSERT, UPDATE, DELETE) ihre SQL-Kompilierung sowie die Konstruktion von Metadaten zum Abrufen von Ergebnissen in den meisten Fällen vollständig cachbar sind. Dies stellt effektiv eine transparente und verallgemeinerte Version dessen dar, was die „Baked Query“-Erweiterung für die ORM in früheren Versionen bot. Die neue Funktion kann den Cache-Schlüssel für jede gegebene SQL-Konstruktion basierend auf der Zeichenkette berechnen, die sie letztendlich für einen bestimmten Dialekt erzeugen würde, sodass Funktionen, die jedes Mal das äquivalente select(), Query(), insert(), update() oder delete()-Objekt zusammensetzen, diese Anweisung nach dem ersten Erzeugen im Cache speichern können.

  Die Funktion ist transparent aktiviert, enthält aber einige neue Programmierparadigmen, die eingesetzt werden können, um das Caching noch effizienter zu gestalten.

  Siehe auch

  Transparente SQL-Kompilierungs-Caching für alle DQL-, DML-Anweisungen in Core und ORM

  SQL-Kompilierungs-Caching

  Referenzen: #4639

• [sql] [bug]

  Fehler behoben, bei dem beim Erstellen von Constraints aus ORM-gebundenen Spalten, hauptsächlich ForeignKey-Objekten, aber auch UniqueConstraint, CheckConstraint und anderen, das ORM-seitige InstrumentedAttribute vollständig verworfen wird und alle ORM-seitigen Annotationen der Spalten entfernt werden; dies geschieht, damit die Constraints weiterhin vollständig pickelbar sind, ohne die ORM-seitigen Entitäten einzubinden. Diese Annotationen sind auf Schema-/Metadatenebene nicht erforderlich.

  Referenzen: #5001

• [sql] [bug]

  Funktionsnamen, die auf GenericFunction basieren, werden nun in allen Fällen case-insensitiv abgerufen, wodurch die Deprecationslogik aus 1.3 entfernt wird, die temporär mehrere GenericFunction-Objekte mit unterschiedlicher Groß-/Kleinschreibung zuließ. Eine GenericFunction, die eine andere mit demselben Namen ersetzt, unabhängig davon, ob die Groß-/Kleinschreibung beachtet wird oder nicht, gibt eine Warnung aus, bevor das Objekt ersetzt wird.

  Referenzen: #4569, #4649

• [sql] [bug]

  Das Erstellen eines and_()- oder or_()-Konstrukts ohne Argumente oder mit leeren *args gibt nun eine Deprecation-Warnung aus, da das erzeugte SQL eine No-Op ist (d.h. es wird als leerer String gerendert). Dieses Verhalten wird als unintuitiv betrachtet, daher sollten für leere oder potenziell leere and_()- oder or_()-Konstrukte ein geeigneter Standard-Booleanwert enthalten sein, wie z.B. and_(True, *args) oder or_(False, *args). Wie bereits seit vielen Hauptversionen von SQLAlchemy üblich, werden diese speziellen booleschen Werte nicht gerendert, wenn der *args-Teil nicht leer ist.

  Referenzen: #5054

• [sql] [bug]

  Der tuple_()-Konstrukt wurde verbessert, sodass er sich im Spaltenkontext vorhersagbar verhält. Das SQL-Tupel wird auf den meisten Backends nicht als Element einer "SELECT"-Spaltenklausel unterstützt; auf denen, die es unterstützen (nicht überraschend, PostgreSQL), hat die Python DBAPI kein Konzept für "verschachtelte Typen", sodass es immer noch Herausforderungen beim Abrufen von Zeilen für ein solches Objekt gibt. Die Verwendung von tuple_() in einem select() oder Query löst nun einen CompileError aus, wenn das tuple_()-Objekt beim Abrufen von Zeilen erscheint (d.h., wenn das Tupel in der Spaltenklausel einer Unterabfrage steht, wird kein Fehler ausgelöst). Für die ORM-Nutzung ist das Bundle-Objekt eine explizite Anweisung, dass eine Reihe von Spalten als Untertupel pro Zeile zurückgegeben werden soll, und wird in der Fehlermeldung vorgeschlagen. Außerdem wird das Tupel nun in allen Kontexten mit Klammern gerendert. Zuvor wurden die Klammern im Spaltenkontext nicht gerendert, was zu undefiniertem Verhalten führte.

  Referenzen: #5127

• [sql] [bug] [postgresql]

  Verbesserte Unterstützung für Spaltennamen, die Prozentzeichen im String enthalten, einschließlich behobener Probleme mit anonymen Labels, die ebenfalls einen Spaltennamen mit einem Prozentzeichen enthielten, sowie wiederhergestellte Unterstützung für gebundene Parameternamen mit eingebetteten Prozentzeichen im psycopg2-Dialekt, unter Verwendung eines späten Escaping-Prozesses, der dem vom cx_Oracle-Dialekt verwendeten ähnelt.

  Referenzen: #5653

• [sql] [bug]

  Benutzerdefinierte Funktionen, die als Unterklassen von FunctionElement erstellt werden, generieren nun eine "anonyme Bezeichnung", basierend auf dem "Namen" der Funktion, genau wie jedes andere Function-Objekt, z.B. "SELECT myfunc() AS myfunc_1". Während SELECT-Anweisungen keine Labels mehr benötigen, damit das Ergebnis-Proxy-Objekt funktioniert, zielt die ORM immer noch auf Spalten in Zeilen ab, indem sie Objekte als Schlüssel für die Zuordnung verwendet, was zuverlässiger funktioniert, wenn die Spaltenausdrücke eindeutige Namen haben. In jedem Fall ist das Verhalten nun konsistent zwischen Funktionen, die von func generiert werden, und solchen, die als benutzerdefinierte FunctionElement-Objekte generiert werden.

  Referenzen: #4887

• [sql] [bug]

  Die ClauseElement.compare()-Methoden wurden auf Basis eines neuen besucherbasierten Ansatzes überarbeitet und zusätzlich eine Testabdeckung hinzugefügt, die sicherstellt, dass alle ClauseElement-Unterklassen strukturell genau verglichen werden können. Die Fähigkeit zum Strukturvergleich wird derzeit in geringem Maße innerhalb der ORM verwendet, könnte aber auch die Grundlage für neue Caching-Funktionen bilden.

  Referenzen: #4336

• [sql] [bug]

  Die Verwendung von DISTINCT ON in anderen Dialekten als PostgreSQL wird als veraltet markiert. Die alte Verwendung von String-Distinct im MySQL-Dialekt wird als veraltet markiert.

  Referenzen: #4002

• [sql] [bug]

  Die ORDER BY-Klausel eines _selectable.CompoundSelect, z.B. UNION, EXCEPT etc., rendert den Tabellennamen, der einer bestimmten Spalte zugeordnet ist, nicht mehr, wenn CompoundSelect.order_by() in Form einer Table-gebundenen Spalte verwendet wird. Die meisten Datenbanken erfordern, dass die Namen in der ORDER BY-Klausel nur als Labelnamen ausgedrückt werden, die mit Namen in der ersten SELECT-Anweisung übereinstimmen. Die Änderung hängt mit #4617 zusammen, da ein früherer Workaround darin bestand, auf das .c-Attribut des _selectable.CompoundSelect zuzugreifen, um an eine Spalte zu gelangen, die keinen Tabellennamen hat. Da die Unterabfrage nun benannt ist, ermöglicht diese Änderung sowohl die Fortsetzung des Workarounds als auch die Verwendung von tabellengebundenen Spalten sowie der CompoundSelect.selected_columns-Sammlungen in der CompoundSelect.order_by()-Methode.

  Referenzen: #4617

• [sql] [bug]

  Das Join-Konstrukt betrachtet die "onclause" nicht mehr als Quelle für zusätzliche FROM-Objekte, die aus der FROM-Liste eines umschließenden Select-Objekts als eigenständige FROM-Objekte weggelassen werden. Dies gilt für eine ON-Klausel, die eine Referenz auf ein anderes FROM-Objekt außerhalb des JOIN enthält; während dies aus SQL-Sicht normalerweise nicht korrekt ist, ist es auch falsch, dass es weggelassen wird, und die Verhaltensänderung lässt die Select / Join etwas intuitiver verhalten.

  Referenzen: #4621

• [sql] [deprecated]

  Die Methode Join.alias() ist veraltet und wird in SQLAlchemy 2.0 entfernt. Stattdessen sollte eine explizite Select + Unterabfrage oder ein Aliasing der inneren Tabellen verwendet werden.

  Referenzen: #5010

• [sql] [deprecated]

  Die Table-Klasse löst nun eine Deprecationswarnung aus, wenn Spalten mit demselben Namen definiert werden. Zum Ersetzen einer Spalte wurde ein neuer Parameter Table.append_column.replace_existing zur Methode Table.append_column() hinzugefügt.

  Die Methode ColumnCollection.contains_column() löst nun einen Fehler aus, wenn sie mit einem String aufgerufen wird, und schlägt dem Aufrufer vor, stattdessen in zu verwenden.

• [sql] [removed]

  Die "threadlocal" Ausführungsstrategie, die in 1.3 als veraltet markiert wurde, wurde für 1.4 entfernt, ebenso wie das Konzept der "Engine-Strategien" und die Methode Engine.contextual_connect. Das Schlüsselwortargument "strategy='mock'" wird vorerst noch mit einer Deprecationswarnung akzeptiert; verwenden Sie stattdessen create_mock_engine() für diesen Anwendungsfall.

  Siehe auch

  Die "threadlocal" Engine-Strategie ist veraltet - aus den Migrationshinweisen von 1.3, die die Begründung für die Veralterung erläutern.

  Referenzen: #4632

• [sql] [removed]

  Die Funktionen sqlalchemy.sql.visitors.iterate_depthfirst und sqlalchemy.sql.visitors.traverse_depthfirst wurden entfernt. Diese Funktionen wurden von keinem Teil von SQLAlchemy verwendet. Die Funktionen iterate() und traverse() werden häufig für diese Funktionen verwendet. Außerdem wurden ungenutzte Optionen aus den verbleibenden Funktionen entfernt, darunter "column_collections" und "schema_visitor".

• [sql] [removed]

  Das Konzept einer gebundenen Engine aus dem Compiler-Objekt wurde entfernt, ebenso wie die Methoden .execute() und .scalar() aus Compiler. Dies waren im Wesentlichen vergessene Methoden aus über einem Jahrzehnt und hatten keinen praktischen Nutzen, und es ist nicht angebracht, dass das Compiler-Objekt selbst eine Referenz auf eine Engine hält.

• [sql] [removed]

  Entfernung der veralteten Methoden Compiled.compile, ClauseElement.__and__ und ClauseElement.__or__ sowie des Attributs Over.func.

  Entfernung der veralteten Methode FromClause.count. Bitte verwenden Sie die Funktion count, die über den func-Namespace verfügbar ist.

  Referenzen: #4643

• [sql] [removed]

  Entfernung der veralteten Parameter text.bindparams und text.typemap. Bitte beziehen Sie sich auf die Methoden TextClause.bindparams() und TextClause.columns().

  Entfernung des veralteten Parameters Table.useexisting. Bitte verwenden Sie stattdessen Table.extend_existing.

  Referenzen: #4643

• [sql] [renamed]

  Der Parameter mustexist der Table wurde in Table.must_exist umbenannt und wird nun bei Verwendung eine Warnung ausgeben.

• [sql] [renamed]

  Die Methoden SelectBase.as_scalar() und Query.as_scalar() wurden in SelectBase.scalar_subquery() bzw. Query.scalar_subquery() umbenannt. Die alten Namen existieren in der 1.4-Serie weiterhin mit einer Deprecationswarnung. Darüber hinaus ist die implizite Konvertierung von SelectBase, Alias und anderen SELECT-orientierten Objekten in Skalar-Unterabfragen, wenn sie in einem Spaltenkontext ausgewertet werden, ebenfalls veraltet und gibt eine Warnung aus, dass die Methode SelectBase.scalar_subquery() explizit aufgerufen werden sollte. Diese Warnung wird in einer späteren Hauptversion zu einem Fehler, jedoch wird die Meldung immer klar sein, wenn SelectBase.scalar_subquery() aufgerufen werden muss. Der letztere Teil der Änderung dient der Klarheit und reduziert die impliziten Entscheidungen des Abfrage-Konvertierungssystems. Die Methode Subquery.as_scalar(), die zuvor Alias.as_scalar war, ist ebenfalls veraltet; .scalar_subquery() sollte direkt von einem select()-Objekt oder Query-Objekt aufgerufen werden.

  Diese Änderung ist Teil der größeren Änderung, select()-Objekte nicht mehr direkt Teil der "from clause"-Klassenhierarchie sein zu lassen, was auch eine Überarbeitung des Klausel-Konvertierungssystems beinhaltet.

  Referenzen: #4617

• [sql] [renamed]

  Mehrere Operatoren wurden umbenannt, um eine konsistentere Benennung über SQLAlchemy hinweg zu erzielen.

  Die Operatoränderungen sind:

  • isfalse ist jetzt is_false

  • isnot_distinct_from ist jetzt is_not_distinct_from

  • istrue ist jetzt is_true

  • notbetween ist jetzt not_between

  • notcontains ist jetzt not_contains

  • notendswith ist jetzt not_endswith

  • notilike ist jetzt not_ilike

  • notlike ist jetzt not_like

  • notmatch ist jetzt not_match

  • notstartswith ist jetzt not_startswith

  • nullsfirst ist jetzt nulls_first

  • nullslast ist jetzt nulls_last

  • isnot ist jetzt is_not

  • notin_ ist jetzt not_in

  Da es sich um Kernoperatoren handelt, besteht die interne Migrationsstrategie für diese Änderung darin, Legacy-Begriffe für einen längeren Zeitraum – wenn nicht unbegrenzt – zu unterstützen, aber alle Dokumentationen, Tutorials und internen Verwendungen auf die neuen Begriffe zu aktualisieren. Die neuen Begriffe werden zur Definition der Funktionen verwendet, und die Legacy-Begriffe wurden zu Aliassen der neuen Begriffe als veraltet markiert.

  Referenzen: #5429, #5435

• [sql] [postgresql]

  Die Angabe des Datentyps beim Erstellen einer Sequence in PostgreSQL wurde durch die Verwendung des Parameters Sequence.data_type ermöglicht.

  Referenzen: #5498

• [sql] [reflection]

  Das Schlüsselwort "NO ACTION" für den Fremdschlüssel "ON UPDATE" wird nun als Standard-Kaskade für einen Fremdschlüssel auf allen unterstützenden Backends (SQLite, MySQL, PostgreSQL) betrachtet und wird, wenn es erkannt wird, nicht im Reflexions-Dictionary enthalten sein; dies ist bereits das Verhalten für PostgreSQL und MySQL für alle früheren SQLAlchemy-Versionen in jedem Fall. Das Schlüsselwort "RESTRICT" wird positiv gespeichert, wenn es erkannt wird; PostgreSQL berichtet über dieses Schlüsselwort, und MySQL ab Version 8.0 tut dies ebenfalls. Auf früheren MySQL-Versionen wird es nicht vom Datenbank gemeldet.

  Referenzen: #4741

• [sql] [reflection]

  Unterstützung für die Reflexion von "identity"-Spalten wurde hinzugefügt, die nun als Teil der von Inspector.get_columns() zurückgegebenen Struktur enthalten sind. Bei der Reflexion vollständiger Table-Objekte werden Identitätsspalten mit dem Identity-Konstrukt dargestellt. Derzeit sind die unterstützten Backends PostgreSQL >= 10, Oracle >= 12 und MSSQL (mit unterschiedlicher Syntax und einer Teilmenge von Funktionalitäten).

  Referenzen: #5324, #5527

schema

• [schema] [change]

  Die Parameter Enum.create_constraint und Boolean.create_constraint sind nun standardmäßig False. Dies bedeutet, dass bei der Erstellung einer sogenannten "nicht-nativen" Version dieser beiden Datentypen standardmäßig keine CHECK-Constraint generiert wird. Diese CHECK-Constraints verursachen Komplexitäten bei der Schemaverwaltung, die explizit aktiviert werden sollten und nicht standardmäßig eingeschaltet sind.

  Siehe auch

  Enum- und Boolean-Datentypen erstellen standardmäßig keine Constraints mehr

  Referenzen: #5367

• [schema] [bug]

  Die interne str()-Darstellung für Datentypen wurde bereinigt, sodass alle Typen eine String-Repräsentation ohne Dialekt erzeugen, einschließlich der Funktionalität für Drittanbieter-Dialekttypen, ohne dass dieser Dialekt vorhanden ist. Die String-Repräsentation ist standardmäßig der GROSSGESCHRIEBENE Name des Typs ohne weitere Zusätze.

  Referenzen: #4262

• [schema] [removed]

  Entfernung der veralteten Klasse Binary. Bitte verwenden Sie stattdessen LargeBinary.

  Referenzen: #4643

• [schema] [renamed]

  Die Methode Table.tometadata() wurde in Table.to_metadata() umbenannt. Der vorherige Name bleibt mit einer Deprecationswarnung bestehen.

  Referenzen: #5413

• [schema] [sql]

  Der Identity-Konstrukt wurde hinzugefügt, der zur Konfiguration von Identitätsspalten mit GENERATED { ALWAYS | BY DEFAULT } AS IDENTITY verwendet werden kann. Derzeit sind die unterstützten Backends PostgreSQL >= 10, Oracle >= 12 und MSSQL (mit unterschiedlicher Syntax und einer Teilmenge von Funktionalitäten).

  Referenzen: #5324, #5360, #5362

extensions

• [extensions] [usecase]

  Benutzerdefinierte Compiler-Konstrukte, die mit der Erweiterung sqlalchemy.ext.compiled erstellt werden, fügen dem Compiler automatisch kontextbezogene Informationen hinzu, wenn ein benutzerdefiniertes Konstrukt als Element in der Spaltenklausel einer SELECT-Anweisung interpretiert wird, sodass das benutzerdefinierte Element als Schlüssel in Ergebniszeilenzuordnungen adressierbar ist, was die Art der Adressierung ist, die die ORM verwendet, um Spaltenelemente in Ergebnis-Tupel zu integrieren.

  Referenzen: #4887

• [extensions] [change]

  Neuer Parameter AutomapBase.prepare.autoload_with hinzugefügt, der AutomapBase.prepare.reflect und AutomapBase.prepare.engine ersetzt.

  Referenzen: #5142

postgresql

• [postgresql] [usecase]

  Unterstützung für die PostgreSQL-Flags "readonly" und "deferrable" für die Dialekte psycopg2, asyncpg und pg8000 hinzugefügt. Dies nutzt eine neu verallgemeinerte Version der "isolation level"-API, um andere Arten von Sitzungsattributen zu unterstützen, die über Ausführungsoptionen gesetzt werden und zuverlässig zurückgesetzt werden, wenn Verbindungen zum Verbindungspool zurückgegeben werden.

  Siehe auch

  Festlegen von READ ONLY / DEFERRABLE

  Referenzen: #5549

• [postgresql] [usecase]

  Die maximale Puffergröße für BufferedRowResultProxy, die von Dialekten wie PostgreSQL bei stream_results=True verwendet wird, kann jetzt auf eine Zahl größer als 1000 gesetzt werden, und der Puffer wächst auf diese Größe. Zuvor ging der Puffer nicht über 1000 hinaus, selbst wenn der Wert größer als dieser war. Das Wachstum des Puffers basiert nun auch auf einem einfachen Multiplikationsfaktor, der derzeit auf 5 gesetzt ist. Pull Request von Soumaya Mauthoor.

  Referenzen: #4914

• [postgresql] [change]

  Bei Verwendung des psycopg2-Dialekts für PostgreSQL ist die Mindestversion von psycopg2 auf 2.7 gesetzt. Der psycopg2-Dialekt basiert auf vielen Funktionen von psycopg2, die in den letzten Jahren veröffentlicht wurden. Um den Dialekt zu vereinfachen, ist nun Version 2.7, veröffentlicht im März 2017, die Mindestanforderung.

• [postgresql] [performance]

  Der psycopg2-Dialekt verwendet nun standardmäßig die sehr performante execute_values() psycopg2-Erweiterung für kompilierte INSERT-Anweisungen und implementiert auch RETURNING-Unterstützung, wenn diese Erweiterung verwendet wird. Dies ermöglicht es INSERT-Anweisungen, selbst solche mit automatisch inkrementierenden SERIAL- oder IDENTITY-Werten, sehr schnell ausgeführt zu werden und trotzdem die neu generierten Primärschlüsselwerte zurückzugeben. Das ORM wird diese neue Funktion in einer separaten Änderung integrieren.

  Siehe auch

  psycopg2-Dialekt-Funktionen „execute_values“ mit RETURNING für INSERT-Anweisungen standardmäßig - vollständige Liste der Änderungen bezüglich des Parameters executemany_mode.

  Referenzen: #5401

• [postgresql] [bug]

  Der pg8000-Dialekt wurde für die neueste Version des pg8000-Treibers für PostgreSQL überarbeitet und modernisiert. Pull Request von Tony Locke. Beachten Sie, dass dies pg8000 auf Version 1.16.6 oder höher festlegt, die keine Python 2-Unterstützung mehr bietet. Python 2-Benutzer, die pg8000 benötigen, sollten sicherstellen, dass ihre Anforderungen auf SQLAlchemy<1.4 gesetzt sind.

• [postgresql] [deprecated]

  Die Dialekte pygresql und py-postgresql sind veraltet.

  Referenzen: #5189

• [postgresql] [removed]

  Unterstützung für veraltete Engine-URLs vom Typ postgres:// entfernt; dies hat viele Jahre lang eine Warnung ausgegeben und Projekte sollten postgresql:// verwenden.

  Referenzen: #4643

mysql

• [mysql] [feature]

  Unterstützung für MariaDB Connector/Python zum MySQL-Dialekt hinzugefügt. Ursprünglicher Pull Request von Georg Richter.

  Referenzen: #5459

• [mysql] [usecase]

  Ein neues Dialekt-Token "mariadb" wurde hinzugefügt, das anstelle von "mysql" in der create_engine()-URL verwendet werden kann. Dies liefert eine MariaDB-Dialekt-Unterklasse von MySQLDialect, die das Flag "is_mariadb" auf True setzt. Der Dialekt gibt einen Fehler aus, wenn eine Server-Versionszeichenkette empfangen wird, die nicht auf MariaDB hinweist. Dies ist nützlich für MariaDB-spezifische Testszenarien sowie zur Unterstützung von Anwendungen, die hartkodiert auf MariaDB-only-Konzepte setzen. Da die Funktionen und Nutzungsmuster von MariaDB und MySQL weiterhin auseinanderdriften, könnte dieses Muster wichtiger werden.

  Referenzen: #5496

• [mysql] [usecase]

  Unterstützung für die Verwendung des Sequence-Konstrukts mit MariaDB 10.3 und höher wurde hinzugefügt, da dies von dieser Datenbank nun unterstützt wird. Das Konstrukt integriert sich in das Table-Objekt genauso wie bei anderen Datenbanken wie PostgreSQL und Oracle; wenn es auf der Integer-Primärschlüssel-"autoincrement"-Spalte vorhanden ist, wird es zur Generierung von Standardwerten verwendet. Zur Abwärtskompatibilität, um eine Table zu unterstützen, die eine Sequence darauf hat, um nur Sequenz-Datenbanken wie Oracle zu unterstützen, aber die Sequenz für MariaDB immer noch nicht auslösen zu lassen, sollte das optionale Flag `optional=True` gesetzt werden, was angibt, dass die Sequenz nur zur Generierung des Primärschlüssels verwendet werden soll, wenn die Zieldatenbank keine andere Option bietet.

  Siehe auch

  Sequenzunterstützung für MariaDB 10.3 hinzugefügt

  Referenzen: #4976

• [mysql] [bug]

  Die MySQL- und MariaDB-Dialekte fragen nun die Systemansicht `information_schema.tables` ab, um festzustellen, ob eine bestimmte Tabelle existiert oder nicht. Zuvor wurde der Befehl "DESCRIBE" mit einer Ausnahmebehandlung verwendet, um nicht existierende Tabellen zu erkennen, was unerwünschterweise einen ROLLBACK auf der Verbindung ausgelöst hätte. Es schienen Legacy-Encoding-Probleme zu bestehen, die die Verwendung von "SHOW TABLES" verhinderten, aber da die MySQL-Unterstützung nun bei 5.0.2 oder höher liegt (gemäß #4189), sind die `information_schema`-Tabellen nun in allen Fällen verfügbar.

• [mysql] [bug]

  Das Schlüsselwort "skip_locked" bei Verwendung von with_for_update() wird auf allen MySQL-Backends als "SKIP LOCKED" gerendert, was bedeutet, dass es für MySQL-Versionen älter als 8 und auf aktuellen MariaDB-Backends fehlschlägt. Dies liegt daran, dass diese Backends "SKIP LOCKED" oder ein Äquivalent nicht unterstützen, sodass dieser Fehler nicht stillschweigend ignoriert werden sollte. Dies wurde von einer Warnung in der 1.3-Serie auf ein Problem hochgestuft.

  Referenzen: #5568

• [mysql] [bug]

  Das Tupel `server_version_info` des MySQL-Dialekts ist nun vollständig numerisch. Zeichenketten-Token wie "MariaDB" sind nicht mehr vorhanden, damit numerische Vergleiche in allen Fällen funktionieren. Das Flag `.is_mariadb` auf dem Dialekt sollte konsultiert werden, um festzustellen, ob MariaDB erkannt wurde. Außerdem wurden Strukturen entfernt, die für extrem alte MySQL-Versionen 3.x und 4.x bestimmt waren; die unterstützte Mindestversion von MySQL ist nun 5.0.2.

  Referenzen: #4189

• [mysql] [deprecated]

  Der OurSQL-Dialekt ist veraltet.

  Referenzen: #5189

• [mysql] [removed]

  Veralteter Dialekt mysql+gaerdbms entfernt, der seit Version 1.0 veraltet war. Verwenden Sie stattdessen direkt den MySQLdb-Dialekt.

  Veralteter Parameter quoting aus ENUM und SET im mysql-Dialekt entfernt. Die an die Enum oder das Set übergebenen Werte werden von SQLAlchemy bei Bedarf automatisch zitiert.

  Referenzen: #4643

sqlite

• [sqlite] [change]

  Unterstützung für die Umschreibung von Rechtsverschachtelungs-JOINs wurde entfernt, um alte SQLite-Versionen vor 3.7.16 (veröffentlicht 2013) zu unterstützen. Es wird erwartet, dass alle modernen Python-Versionen unter den aktuell unterstützten wesentlich neuere SQLite-Versionen enthalten sollten.

  Siehe auch

  Logik zur "JOIN-Umschreibung" aus dem SQLite-Dialekt entfernt; Importe aktualisiert

  Referenzen: #4895

mssql

• [mssql] [feature] [sql]

  Unterstützung für den JSON-Datentyp auf dem SQL Server-Dialekt wurde hinzugefügt, unter Verwendung der JSON-Implementierung. Diese implementiert die JSON-Funktionalität von SQL Server gegen den NVARCHAR(max)-Datentyp gemäß der SQL Server-Dokumentation. Implementierung von Gord Thompson.

  Referenzen: #4384

• [mssql] [feature]

  "CREATE SEQUENCE" und vollständige Sequence-Unterstützung für Microsoft SQL Server wurde hinzugefügt. Dies entfernt die veraltete Funktion zur Verwendung von Sequence-Objekten zur Manipulation von IDENTITY-Merkmalen, die nun über mssql_identity_start und mssql_identity_increment erfolgen sollte, wie unter Auto Increment Behavior / IDENTITY Columns dokumentiert. Die Änderung beinhaltet einen neuen Parameter Sequence.data_type, um den Datentyp-Wahl von SQL Server zu berücksichtigen, der für dieses Backend INTEGER, BIGINT und DECIMAL(n, 0) umfasst. Der Standardstartwert für die Version von Sequence von SQL Server wurde auf 1 gesetzt; dieser Standard wird nun innerhalb des CREATE SEQUENCE DDL für alle Backends ausgegeben.

  Siehe auch

  Sequenzunterstützung, getrennt von IDENTITY, für SQL Server hinzugefügt

  Referenzen: #4235, #4633

• [mssql] [usecase] [postgresql] [reflection] [schema]

  Verbesserte Unterstützung für Covering Indexes (mit INCLUDE-Spalten). Die Möglichkeit für PostgreSQL hinzugefügt, CREATE INDEX-Anweisungen mit einer INCLUDE-Klausel aus Core zu rendern. Die Index-Reflexion meldet auch INCLUDE-Spalten separat für mssql und postgresql (11+).

  Referenzen: #4458

• [mssql] [usecase] [postgresql]

  Unterstützung für die Inspektion/Reflexion von partiellen Indizes/gefilterten Indizes, d.h. solchen, die die Parameter mssql_where oder postgresql_where verwenden, mit Index hinzugefügt. Der Eintrag ist sowohl Teil des von Inspector.get_indexes() zurückgegebenen Dictionaries als auch Teil eines reflektierten Index-Konstrukts, das reflektiert wurde. Pull Request von Ramon Williams.

  Referenzen: #4966

• [mssql] [usecase] [reflection]

  Unterstützung für die Reflexion von temporären Tabellen mit dem SQL Server-Dialekt hinzugefügt. Tabellennamen, die mit einem Rautezeichen "#" präfigiert sind, werden nun aus dem MSSQL "tempdb" Systemkatalog introspektiert.

  Referenzen: #5506

• [mssql] [change]

  SQL Server OFFSET- und FETCH-Schlüsselwörter werden nun für Limit/Offset verwendet, anstatt eine Fensterfunktion zu verwenden, für SQL Server-Versionen ab 11. TOP wird weiterhin für Abfragen verwendet, die nur LIMIT enthalten. Pull Request von Elkin.

  Referenzen: #5084

• [mssql] [bug] [schema]

  Ein Problem behoben, bei dem sqlalchemy.engine.reflection.has_table() immer False für temporäre Tabellen zurückgab.

  Referenzen: #5597

• [mssql] [bug]

  Die Basisklasse des DATETIMEOFFSET-Datentyps wurde korrigiert, um auf der DateTime-Klassen-Hierarchie zu basieren, da es sich um einen Datum-/Zeitwert speichernden Datentyp handelt.

  Referenzen: #4980

• [mssql] [deprecated]

  Die Dialekte adodbapi und mxODBC sind veraltet.

  Referenzen: #5189

• [mssql]

  Der mssql-Dialekt geht davon aus, dass mindestens MSSQL 2005 verwendet wird. Es wird keine harte Ausnahme ausgelöst, wenn eine frühere Version erkannt wird, aber Operationen können für ältere Versionen fehlschlagen.

• [mssql] [reflection]

  Als Teil der Unterstützung für die Reflexion von Identity-Objekten gibt die Methode Inspector.get_columns() mssql_identity_start und mssql_identity_increment nicht mehr als Teil von dialect_options zurück. Verwenden Sie stattdessen die Informationen im Schlüssel identity.

  Referenzen: #5527

• [mssql] [engine]

  Der Parameter legacy_schema_aliasing für sqlalchemy.create_engine() ist veraltet. Dies ist ein lange veralteter Parameter, der seit Version 1.1 standardmäßig auf False gesetzt ist.

  Referenzen: #4809

oracle

• [oracle] [usecase]

  Die `max_identifier_length` für den Oracle-Dialekt beträgt standardmäßig 128 Zeichen, es sei denn, die Kompatibilitätsversion ist kleiner als 12.2 bei der ersten Verbindung. In diesem Fall wird die Legacy-Länge von 30 Zeichen verwendet. Dies ist eine Fortsetzung des Problems, das in der 1.3-Serie eingeführt wurde, und fügt die Erkennung der maximalen Bezeichnerlänge bei der ersten Verbindung hinzu und gibt eine Warnung für die Änderung des Oracle-Servers aus.

  Siehe auch

  Maximale Bezeichnerlängen - in der Oracle-Dialektdokumentation

  Referenzen: #4857

• [oracle] [change]

  Das LIMIT / OFFSET-Schema, das in Oracle verwendet wird, verwendet nun benannte Unterabfragen anstelle von unbenannten Unterabfragen, wenn eine SELECT-Anweisung transparent in eine umgeschrieben wird, die ROWNUM enthält. Die Änderung ist Teil einer größeren Änderung, bei der unbenannte Unterabfragen von Core nicht mehr direkt unterstützt werden, sowie zur Modernisierung der internen Verwendung des `select()`-Konstrukts innerhalb des Oracle-Dialekts.

• [oracle] [bug]

  Die Optionen nominvalue und nomaxvalue für die Spalten Sequence und Identity werden nun korrekt als NOMAXVALUE und NOMINVALUE auf der Oracle-Datenbank gerendert.

• [oracle] [bug]

  Die Klasse INTERVAL des Oracle-Dialekts ist nun korrekt eine Unterklasse der abstrakten Version von Interval sowie der korrekten "emulierten" Basisklasse, was korrektes Verhalten sowohl im nativen als auch im nicht-nativen Modus ermöglicht; zuvor basierte sie nur auf TypeEngine.

  Referenzen: #4971

misc

• [deprecated] [firebird]

  Der Firebird-Dialekt ist veraltet, da es nun einen 3rd-Party-Dialekt gibt, der diese Datenbank unterstützt.

  Referenzen: #5189

• [misc] [deprecated]

  Der Sybase-Dialekt ist veraltet.

  Referenzen: #5189