2.0 Changelog

2.0.40

kein Veröffentlichungsdatum

2.0.39

Veröffentlicht: 11. März 2025

orm

• [orm] [bug]

  Fehler behoben, bei dem die Verwendung von DML-Rückgaben wie Insert.returning() mit einem ORM-Modell, das column_property()-Konstrukte enthielt, die Unterabfragen enthielten, zu einem internen Fehler führte.

  Referenzen: #12326

• [orm] [bug]

  Fehler in ORM-aktiviertem UPDATE (und theoretisch DELETE) behoben, bei dem die Verwendung einer Multi-Table-DML-Anweisung nicht zuließ, dass ORM-zugeordnete Spalten von Mappern, die nicht der primäre UPDATE-Mapper waren, in der RETURNING-Klausel genannt wurden; sie wurden stattdessen weggelassen und führten zu einer Ausnahme wegen nicht gefundener Spalte.

  Referenzen: #12328

• [orm] [bug]

  Problem behoben, bei dem das "ist ORM"-Flag einer select() oder einer anderen ORM-Anweisung nicht an die ORM Session weitergegeben wurde, die auf einem mehrteiligen Operator-Ausdruck allein basierte, z. B. Cls.attr + Cls.attr + Cls.attr oder ähnlichem, was dazu führte, dass ORM-Verhaltensweisen für solche Anweisungen nicht wirksam wurden.

  Referenzen: #12357

• [orm] [bug]

  Problem behoben, bei dem die Verwendung von aliased() um ein CTE-Konstrukt herum zu unangemessenen "doppelten CTE"-Fehlern führen konnte, wenn dieses aliasierte Konstrukt mehrmals in einer einzigen Anweisung vorkam.

  Referenzen: #12364

sql

• [sql] [bug]

  Neue Parameter AddConstraint.isolate_from_table und DropConstraint.isolate_from_table hinzugefügt, die standardmäßig auf True gesetzt sind und das seit langem bestehende Verhalten dieser beiden Konstrukte dokumentieren und steuerbar machen, dass die gegebene Einschränkung nicht inline in die "CREATE TABLE"-Sequenz aufgenommen wird, unter der Annahme, dass separate Add/Drop-Direktiven verwendet werden sollten.

  Referenzen: #12382

typing

• [typing] [usecase]

  Unterstützung für generische Typen für zusammengesetzte Abfragen (union(), union_all(), Select.union(), Select.union_all(), etc.) gibt den Typ der ersten Abfrage zurück. Pull-Request von Mingyu Park.

  Referenzen: #11922

asyncio

• [asyncio] [bug]

  Fehler behoben, bei dem AsyncResult.scalar(), AsyncResult.scalar_one_or_none() und AsyncResult.scalar_one() einen AttributeError aufgrund eines fehlenden internen Attributs auslösten. Pull-Request von Allen Ho.

  Referenzen: #12338

postgresql

• [postgresql] [bug]

  SQL-Typisierung zur Reflexionsabfrage hinzugefügt, die verwendet wird, um die Struktur von IDENTITY-Spalten abzurufen, und explizite JSON-Typisierung zur Abfrage hinzugefügt, um ungewöhnliche PostgreSQL-Treiberkonfigurationen zu unterstützen, die JSON nicht nativ unterstützen.

  Referenzen: #11751

• [postgresql] [bug]

  Problem behoben, das PostgreSQL 17.3 und höher betraf, bei dem die Reflexion von Domänen mit "NOT NULL" als Teil ihrer Definition einen ungültigen Einschränkungseintrag in den von PGInspector.get_domains() zurückgegebenen Daten enthielt, der einer zusätzlichen "NOT NULL"-Einschränkung entsprach, die keine CHECK-Einschränkung ist; der vorhandene Eintrag "nullable" im Wörterbuch gibt bereits an, ob die Domäne eine "not null"-Einschränkung enthält. Beachten Sie, dass solche Domänen auf PostgreSQL 17.0 bis 17.2 aufgrund eines Fehlers auf der PostgreSQL-Seite nicht reflektiert werden können; wenn Fehler bei der Reflexion von Domänen auftreten, die NOT NULL enthalten, aktualisieren Sie auf PostgreSQL Server 17.3 oder höher.

• [postgresql] [bug]

  Problem bei PostgreSQL-Netzwerktypen INET, CIDR, MACADDR, MACADDR8 behoben, bei dem das Senden von Zeichenkettenwerten zum Vergleich mit diesen Typen eine explizite Umwandlung in VARCHAR ergab, was dazu führte, dass einige SQL-/Treiberkombinationen fehlschlugen. Pull-Request von Denis Laxalde.

  Referenzen: #12060

• [postgresql] [bug]

  Compilerproblem im PostgreSQL-Dialekt behoben, bei dem falsche Schlüsselwörter übergeben wurden, wenn "FOR UPDATE OF" innerhalb einer Unterabfrage verwendet wurde.

  Referenzen: #12417

sqlite

• [sqlite] [bug]

  Problem behoben, das das Komma zwischen mehreren SQLite-Tabellenerweiterungsklauseln, aktuell WITH ROWID und STRICT, wegließ, wenn beide Optionen Table.sqlite_with_rowid und Table.sqlite_strict gleichzeitig mit ihren nicht standardmäßigen Einstellungen konfiguriert waren. Pull-Request von david-fed.

  Referenzen: #12368

2.0.38

Veröffentlicht: 6. Februar 2025

engine

• [engine] [bug]

  Problem mit Ereignissen behoben, bei dem die mehrfache Aufrufung von Engine.execution_options() auf eine Engine unter Verwendung von Ereignisregistrierungsparametern wie isolation_level zu internen Fehlern bei der Ereignisregistrierung führte.

  Referenzen: #12289

sql

• [sql] [bug]

  Die internen Mechanismen, durch die die `.c`-Sammlung auf einer FromClause generiert wird, wurden neu organisiert, um gegen den gleichzeitigen Zugriff auf die Sammlung resistent zu sein. Ein Beispiel ist die Erstellung eines Alias oder einer Subquery und der Zugriff darauf als Modulvariable. Dies betrifft den Oracle-Dialekt, der solche globalen Alias-Objekte auf Modulebene verwendet, ist aber auch allgemein nützlich.

  Referenzen: #12302

• [sql] [bug]

  Problem mit der SQL-Komposition behoben, das das Caching beeinträchtigte, bei dem die Verwendung eines `None`-Werts innerhalb eines `in_()`-Ausdrucks die übliche "erweiterte Bindungsparameter"-Logik umging, die vom IN-Konstrukt verwendet wird und ein korrektes Caching ermöglicht.

  Referenzen: #12314

postgresql

• [postgresql] [usecase] [asyncio]

  Ein zusätzlicher Aufruf von `asyncio.shield()` wurde in den Verbindungstrennprozess des asyncpg-Treibers aufgenommen, um ein Problem zu mildern, bei dem die Trennung unter der anyio-Concurrency-Bibliothek nicht abgeschlossen werden konnte.

  Referenzen: #12077

• [postgresql] [bug]

  Der asynchronpg-Verbindungswrapper wurde angepasst, sodass der `connection.transaction()`-Aufruf an asyncpg `None` für `isolation_level` sendet, wenn dies nicht anders im SQLAlchemy-Dialekt/Wrapper eingestellt ist, wodurch asyncpg die serverseitige Einstellung für `isolation_level` in Abwesenheit einer clientseitigen Einstellung nutzen kann. Zuvor wurde dieses Verhalten von asyncpg durch ein fest kodiertes `read_committed` blockiert.

  Referenzen: #12159

mariadb

• [mariadb] [bug] [dml] [mysql]

  Fehler behoben, bei dem der MySQL-Anweisungskompilierer Anweisungen, bei denen Insert.on_duplicate_key_update() Werte übergeben wurden, die ORM-zugeordnete Attribute (z. B. `InstrumentedAttribute`-Objekte) als Schlüssel enthielten, nicht korrekt kompilierte. Pull-Request von mingyu.

  Referenzen: #12117

sqlite

• [sqlite] [bug] [aiosqlite] [asyncio] [pool]

  Standardverbindungspool des `aiosqlite`-Dialekts von `NullPool` auf `AsyncAdaptedQueuePool` geändert; diese Änderung hätte gemacht werden sollen, als 2.0 zum ersten Mal veröffentlicht wurde, da der `pysqlite`-Dialekt ähnlich zu `QueuePool` geändert wurde, wie in Der SQLite-Dialekt verwendet QueuePool für dateibasierte Datenbanken beschrieben.

  Referenzen: #12285

2.0.37

Veröffentlicht: 9. Januar 2025

orm

• [orm] [bug]

  Problem mit `Union`-Typen behoben, die in der `registry.type_annotation_map` eines `registry` oder einer deklarativen Basisklasse vorhanden waren, bei denen ein `Mapped`-Element, das einen der Untertypen enthielt, die in dieser `Union` vorhanden waren, mit diesem Eintrag übereinstimmte und möglicherweise andere Einträge ignorierte, die exakt übereinstimmten. Das richtige Verhalten tritt nun ein, sodass ein Eintrag in `registry.type_annotation_map` nur exakt übereinstimmen sollte, da ein `Union`-Typ ein in sich geschlossener Typ ist. Zum Beispiel würde ein Attribut mit `Mapped[float]` zuvor mit einem `registry.type_annotation_map`-Eintrag `Union[float, Decimal]` übereinstimmen; dies wird nicht mehr übereinstimmen und wird nun nur noch mit einem Eintrag übereinstimmen, der `float` angibt. Pull-Request von Frazer McLean.

  Referenzen: #11370

• [orm] [bug]

  Fehler bei der Behandlung von Typ-Unionen in `registry.type_annotation_map` sowie in `Mapped` behoben, die das Nachschlageverhalten von `a | b` anders als das von `Union[a, b]` machte.

  Referenzen: #11944

• [orm] [bug]

  Konsistente Handhabung von `TypeAliasType` (definiert in PEP 695), die mit der Syntax `type X = int` erhalten wird, die in Python 3.12 eingeführt wurde. Nun muss in allen Fällen ein solcher Alias explizit zur Typzuordnung hinzugefügt werden, damit er innerhalb von `Mapped` verwendet werden kann. Diese Änderung überarbeitet auch den in `#11305` hinzugefügten Ansatz, der nun verlangt, dass `TypeAliasType` zur Typzuordnung hinzugefügt wird. Dokumentation zur Handhabung von Unionen und Typ-Alias-Typen durch SQLAlchemy wurde im Abschnitt Anpassung der Typenzuordnung der Dokumentation hinzugefügt.

  Referenzen: #11955

• [orm] [bug]

  Regression behoben, die durch eine interne Codeänderung als Reaktion auf neuere Mypy-Versionen verursacht wurde und den sehr ungewöhnlichen Fall, dass eine Liste von ORM-zugeordneten Attributausdrücken an `ColumnOperators.in_()` übergeben wurde, nicht mehr akzeptierte.

  Referenzen: #12019

• [orm] [bug]

  Probleme bei der Typbehandlung innerhalb des `registry.type_annotation_map`-Features behoben, die die Verwendung von Unionen (sowohl mit Pep-604- als auch mit `Union`-Syntaxen im Zukunft-Annotationen-Modus) mit mehreren generischen Typen als Elementen an einer korrekten Auflösung hinderten.

  Referenzen: #12207

• [orm] [bug]

  Problem im Ereignissystem behoben, das verhinderte, dass ein Ereignis-Listener an mehrere klassenartige Objekte angehängt und von ihnen gelöst wurde, nämlich die Ziele `sessionmaker` oder `scoped_session`, die an `Session`-Unterklassen zugewiesen werden.

  Referenzen: #12216

sql

• [sql] [bug]

  Problem im "Lambda SQL"-Feature behoben, bei dem die Verfolgung von gebundenen Parametern beschädigt werden konnte, wenn dasselbe Lambda über mehrere Kompilierungsphasen ausgewertet wurde, auch bei Verwendung desselben Lambdas über mehrere Engine-Instanzen hinweg oder bei deaktiviertem Statement-Caching.

  Referenzen: #12084

postgresql

• [postgresql] [usecase]

  Der `Range`-Typ unterstützt nun `Range.__contains__()`. Pull-Request von Frazer McLean.

  Referenzen: #12093

• [postgresql] [bug]

  Problem mit `Dialect.get_multi_indexes()` im PostgreSQL-Dialekt behoben, bei dem ein Fehler auftrat, wenn versucht wurde, Alembic mit einem Vektorindex aus der pgvecto.rs-Erweiterung zu verwenden.

  Referenzen: #11724

• [postgresql] [bug]

  Problem behoben, bei dem das Erstellen einer Tabelle mit einer Primärspalte vom Typ `SmallInteger` und der Verwendung des asyncpg-Treibers dazu führte, dass der Typ zu `SERIAL` statt `SMALLSERIAL` kompiliert wurde.

  Referenzen: #12170

• [postgresql] [bug]

  Der asyncpg-Dialekt wurde angepasst, sodass eine leere SQL-Zeichenkette, die für PostgreSQL Server gültig ist, auf Dialektebene erfolgreich verarbeitet werden kann, z. B. bei der Verwendung von `Connection.exec_driver_sql()`. Pull-Request von Andrew Jackson.

  Referenzen: #12220

mysql

• [mysql] [usecase] [mariadb]

  Unterstützung für die `LIMIT`-Klausel bei `DELETE` für die Dialekte MySQL und MariaDB hinzugefügt, um die bereits vorhandene Option für `UPDATE` zu ergänzen. Die Methode `Delete.with_dialect_options()` des `delete()`-Konstrukts akzeptiert Parameter für `mysql_limit` und `mariadb_limit`, wodurch Benutzer eine Begrenzung der gelöschten Zeilen angeben können. Pull-Request von Pablo Nicolás Estevez.

  Referenzen: #11764

• [mysql] [bug] [mariadb]

  Logik hinzugefügt, um sicherzustellen, dass die Parameter `mysql_limit` und `mariadb_limit` von `Update.with_dialect_options()` und `Delete.with_dialect_options()` beim Kompilieren zu Strings nur dann kompiliert werden, wenn der Parameter als Ganzzahl übergeben wird; andernfalls wird ein `ValueError` ausgelöst.

mariadb

• [mariadb] [usecase]

  Hinzugefügte SQL-Typen INET4 und INET6 im MariaDB-Dialekt. Pull-Request von Adam Žurek.

  Referenzen: #10720

sqlite

• [sqlite] [anwendungsfall]

  SQLite-Tabellenoption hinzugefügt, um STRICT-Tabellen zu aktivieren. Pull-Request von Guilherme Crocetti.

  Referenzen: #7398

oracle

• [oracle] [funktion]

  Neue Tabellenoption oracle_tablespace hinzugefügt, um die Option TABLESPACE beim Erstellen einer Tabelle in Oracle anzugeben. Dies ermöglicht Benutzern die Definition des Tablespace, in dem die Tabelle erstellt werden soll. Pull-Request von Miguel Grillo.

  Referenzen: #12016

• [oracle] [anwendungsfall]

  Das Verbindungsattribut max_identifier_length, das in oracledb ab Version 2.5 verfügbar ist, wird bei der Bestimmung der Bezeichnerlänge im Oracle-Dialekt verwendet.

  Referenzen: #12032

• [oracle] [fehler]

  Kompilierung der Funktion TABLE korrigiert, wenn sie in einer FROM-Klausel im Oracle Database-Dialekt verwendet wird.

  Referenzen: #12100

• [oracle] [fehler]

  Problem in den Dialekten oracledb / cx_oracle behoben, bei dem Ausgabetyp-Handler für CLOB an NVARCHAR statt an VARCHAR weitergeleitet wurden, was zu einer doppelten Konvertierung führte.

  Referenzen: #12150

2.0.36

Veröffentlicht: 15. Oktober 2024

orm

• [orm] [anwendungsfall]

  Neuer Parameter mapped_column.hash zu ORM-Konstrukten wie sqlalchemy.orm.mapped_column(), sqlalchemy.orm.relationship() usw. hinzugefügt, der für ORM Native Dataclasses genauso interpretiert wird wie andere datenklassen-spezifische Feldparameter.

  Referenzen: #11923

• [orm] [fehler]

  Fehler bei der ORM-Massenaktualisierung/-löschung behoben, bei der die Verwendung von RETURNING mit Massenaktualisierung/-löschung in Kombination mit populate_existing die Option populate_existing nicht berücksichtigen konnte.

  Referenzen: #11912

• [orm] [fehler]

  Aufbauend auf #11912 werden Spalten, die mit mapped_column.onupdate, mapped_column.server_onupdate oder Computed gekennzeichnet sind, nun in ORM-Instanzen aktualisiert, wenn ein ORM-fähiges UPDATE mit WHERE-Kriterien ausgeführt wird, auch wenn die Anweisung kein RETURNING oder populate_existing verwendet.

  Referenzen: #11917

• [orm] [fehler]

  Regressionsfehler behoben, der durch Korrekturen am gestaffelten Eager Loading in #11449, veröffentlicht in 2.0.31, entstanden war, bei dem ein bestimmter Fall von joinedload nicht korrekt geprüft werden konnte. Wir haben nun ein Beispiel für diesen Fall, sodass die Überprüfung repariert wurde, um ihn zu ermöglichen.

  Referenzen: #11965

• [orm] [fehler]

  Verbesserte Fehlermeldung, die ausgegeben wird, wenn versucht wird, eine Klasse als Datenklasse zu mappen und gleichzeitig manuell das Attribut __table__ anzugeben. Diese Verwendung wird derzeit nicht unterstützt.

  Referenzen: #11973

• [orm] [fehler]

  Die Prüfung, die der ORM-Lazy-Loader verwendet, um „dies würde eine Ladung nach Primärschlüssel sein und der Primärschlüssel ist NULL, Ladung überspringen“ zu erkennen, wurde verfeinert, um die aktuelle Einstellung für den Parameter Mapper.allow_partial_pks zu berücksichtigen. Wenn dieser Parameter False ist, sollte auch ein zusammengesetzter PK-Wert mit teilweisen NULL-Elementen übersprungen werden. Dies kann für einige zusammengesetzte überlappende Fremdschlüsselkonfigurationen gelten.

  Referenzen: #11995

• [orm] [fehler]

  Fehler in der ORM-Funktion „Update mit WHERE-Klausel“ behoben, bei der ein explizites .returning() die „fetch“-Synchronisierungsstrategie beeinträchtigte, aufgrund einer Annahme, dass die ORM-gemappte Klasse die Primärschlüsselspalten an einer bestimmten Position innerhalb von RETURNING enthielt. Dies wurde behoben, um die entsprechende ORM-Spaltenausrichtung zu verwenden.

  Referenzen: #11997

sql

• [sql] [anwendungsfall]

  Binärbasierte Datentypen wie VARBINARY werden beim Aufruf der Methode TypeEngine.as_generic() zu LargeBinary aufgelöst.

  Referenzen: #11978

• [sql] [fehler] [regression]

  Regression aus 1.4 behoben, bei der einige Datentypen, wie z. B. von TypeDecorator abgeleitete, nicht gepickelt werden konnten, wenn sie Teil einer größeren SQL-Ausdruckskomposition waren, da die internen unterstützenden Strukturen selbst nicht pickelbar waren.

  Referenzen: #12002

schema

• [schema] [fehler]

  Fehler behoben, bei dem SQL-Funktionen, die an Column.server_default übergeben wurden, nicht mit der spezifischen Klammerung gerendert wurden, die neuere Versionen von MySQL und MariaDB erfordern. Pull-Request von huuya.

  Referenzen: #11317

postgresql

• [postgresql] [fehler] [reflection]

  Fehler bei der Reflexion von Tabellenkommentaren behoben, bei dem nicht zusammenhängender Text zurückgegeben wurde, wenn ein Eintrag in der Tabelle pg_description zufällig die gleiche oid (objoid) wie die zu reflektierende Tabelle teilte.

  Referenzen: #11961

• [postgresql] [fehler]

  Die Datentypen JSON und JSONB rendern nun in allen Fällen einen „Bind-Cast“ für alle PostgreSQL-Backends, einschließlich psycopg2, während dies zuvor nur für einige Backends aktiviert war. Dies ermöglicht eine höhere Genauigkeit, indem dem Datenbankserver ermöglicht wird, zu erkennen, wann ein Zeichenfolgenwert als JSON interpretiert werden soll.

  Referenzen: #11994

mysql

• [mysql] [performance]

  Eine Abfrage für das MySQL 8-Backend zur Reflexion von Fremdschlüsseln wurde zur besseren Optimierung verbessert. Zuvor konnte die Abfrage für eine Datenbank mit Millionen von Spalten über alle Tabellen hinweg prohibitiv langsam sein; die Abfrage wurde überarbeitet, um vorhandene Indizes besser zu nutzen.

  Referenzen: #11975

2.0.35

Veröffentlicht: 16. September 2024

orm

• [orm] [fehler] [typing]

  Problem behoben, bei dem typing.Literal mit Mapped[] unter Python 3.8 und 3.9 nicht verwendet werden konnte. Pull-Request von Frazer McLean.

  Referenzen: #11820

• [orm] [fehler]

  Problem im ORM-Evaluator behoben, bei dem zwei Datentypen, die mit dem SQL-Konkatenator-Operator ausgewertet wurden, nicht auf UnevaluatableError basierend auf ihrem Datentyp geprüft wurden; dies übersah den Fall, dass JSONB-Werte in einer Konkatenationsoperation verwendet wurden, die von PostgreSQL unterstützt wird, sowie wie SQLAlchemy die SQL für diese Operation rendert, aber auf Python-Ebene nicht funktioniert. Durch die Implementierung von UnevaluatableError für diese Kombination fallen ORM-Update-Anweisungen nun auf „expire“ zurück, wenn ein verknüpfter JSON-Wert, der in einer SET-Klausel verwendet wird, mit einem Python-Objekt synchronisiert werden soll.

  Referenzen: #11849

• [orm] [fehler]

  Eine Warnung wird ausgegeben, wenn joinedload() oder subqueryload() als oberste Option gegen eine Anweisung verwendet werden, die keine SELECT-Anweisung ist, z. B. mit einem insert().returning(). Bei INSERT-Anweisungen gibt es keine JOINs, noch gibt es eine „Subquery“, die für Subquery Eager Loading wiederverwendet werden kann, und für UPDATE/DELETE unterstützen joinedload dies ebenfalls nicht, sodass diese Verwendung niemals stillschweigend akzeptabel ist.

  Referenzen: #11853

• [orm] [fehler]

  Problem behoben, bei dem die Verwendung von Loader-Optionen wie selectinload() mit zusätzlichen Kriterien in Kombination mit ORM DML wie insert() mit RETURNING interne Kontexte, die für das korrekte Funktionieren des Caching erforderlich sind, nicht korrekt eingerichtet hat, was zu falschen Ergebnissen führte.

  Referenzen: #11855

mysql

• [mysql] [fehler]

  Problem im mariadbconnector-Dialekt behoben, bei dem Abfragezeichenfolgenargumente, die keine Integer- oder Booleschen Argumente waren, ignoriert wurden, wie z. B. Zeichenfolgenargumente wie unix_socket usw. Als Teil dieser Änderung wurde die Argumentenanalyse für bestimmte Elemente wie client_flags, compress, local_infile über alle MySQL / MariaDB-Dialekte hinweg konsistenter gestaltet, die jedes Argument akzeptieren. Pull-Request von Tobias Alex-Petersen.

  Referenzen: #11870

sqlite

• [sqlite] [fehler] [regression]

  Die Änderungen an der Reflexion von SQLite CHECK-Constraints in den Versionen 2.0.33 und 2.0.34 (#11832 und #11677) wurden nun vollständig rückgängig gemacht, da Benutzer weiterhin Anwendungsfälle identifizierten, die nach dieser Änderung nicht mehr funktionierten. Derzeit, da SQLite keine konsistente Methode zur Bereitstellung von Informationen über CHECK-Constraints bietet, ist SQLAlchemy in Bezug auf die zu reflektierenden CHECK-Constraint-Syntaxen eingeschränkt, einschließlich der Tatsache, dass ein CHECK-Constraint in einer einzigen, unabhängigen Zeile (oder inline bei einer Spaltendefinition) ohne Zeilenumbrüche, Tabs in der Constraint-Definition oder ungewöhnliche Zeichen im Constraint-Namen angegeben werden muss. Insgesamt ist die Reflexion für SQLite darauf ausgelegt, CREATE TABLE-Anweisungen reflektieren zu können, die ursprünglich von SQLAlchemy DDL-Konstrukten erstellt wurden. Langfristige Arbeiten an einem DDL-Parser, der nicht auf regulären Ausdrücken basiert, können diese Situation möglicherweise verbessern. Eine breite Palette zusätzlicher übergreifender CHECK-Constraint-Reflexionstests wurde hinzugefügt, da es auch ein Fehler war, dass diese Änderungen keine vorhandenen Tests ausgelöst haben.

  Referenzen: #11840

2.0.34

Veröffentlicht: 4. September 2024

orm

• [orm] [fehler]

  Regressionsfehler behoben, der durch Problem #11814 entstanden war und die Unterstützung für bestimmte Varianten von PEP 593 Annotated in der type_annotation_map brach, wenn eingebaute Typen wie list, dict ohne Elementtyp verwendet wurden. Obwohl dies ein unvollständiger Tippstil ist, wurden diese Typen dennoch zuvor korrekt in der type_annotation_map gefunden.

  Referenzen: #11831

sqlite

• [sqlite] [fehler]

  Regressionsfehler in der SQLite-Reflexion behoben, der durch #11677 verursacht wurde und die Reflexion von CHECK-Constraints beeinträchtigte, die von anderen Arten von Constraints innerhalb derselben Tabellendefinition gefolgt wurden. Pull-Request von Harutaka Kawamura.

  Referenzen: #11832

2.0.33

Veröffentlicht: 3. September 2024

general

• [general] [änderung]

  Die Einschränkung für setuptools<69.3 in pyproject.toml wurde entfernt. Diese Einschränkung sollte eine plötzliche Änderung in setuptools verhindern, PEP 625 zu verwenden, die den Dateinamen der SQLAlchemy-Quelldistribution auf PyPI zu einem kleingeschriebenen Namen ändern würde, was wahrscheinlich Probleme mit verschiedenen Build-Umgebungen verursachen würde, die den früheren Benennungsstil erwarteten. Die Anwesenheit dieser Einschränkung hält jedoch Umgebungen zurück, die ansonsten ein neueres setuptools verwenden möchten, daher haben wir uns entschieden, mit dieser Änderung fortzufahren, unter der Annahme, dass Build-Umgebungen die setuptools-Änderung inzwischen weitgehend angepasst haben.

  Referenzen: #11818

orm

• [orm] [fehler] [regression]

  Regressionsfehler aus 1.3 behoben, bei dem der für eine Hybrid-Eigenschaft verwendete Spaltenschlüssel mit dem der zugrunde liegenden Spalte gefüllt werden konnte, die sie zurückgibt, für eine Eigenschaft, die direkt eine ORM-gemappte Spalte zurückgibt, anstatt des Schlüssels, der von der Hybrid-Eigenschaft selbst verwendet wird.

  Diese Änderung wird auch zurückportiert nach: 1.4.54

  Referenzen: #11728

• [orm] [fehler]

  Die interne Modulregistrierung auf oberster Ebene wird korrekt aufgeräumt, wenn keine inneren Module oder Klassen darin registriert sind.

  Referenzen: #11788

• [orm] [fehler]

  Verbesserungen bei der ORM-Erkennung des annotierten deklarativen Typen-Maps, die zusammengesetzte Typen wie dict[str, Any] mit oder ohne „future annotations“-Modus behandeln, die auf JSON (oder andere) verweisen.

  Referenzen: #11814

engine

• [engine] [fehler]

  Problem im internen Reflexionscache behoben, bei dem bestimmte Reflexionsszenarien bezüglich gleichnamiger quoted_name()-Konstrukte nicht korrekt gecached wurden. Pull-Request von Felix Lüdin.

  Referenzen: #11687

sql

• [sql] [fehler] [regression]

  Regressionsfehler in Select.with_statement_hint() und anderen behoben, bei denen das generative Verhalten der Methode keine Kopie des Objekts mehr erzeugte.

  Referenzen: #11703

schema

• [schema] [fehler]

  Fehler behoben, bei dem das metadata-Element eines Enum-Datentyps nicht an das neue MetaData-Objekt übertragen wurde, wenn der Typ über eine Table.to_metadata()-Operation kopiert worden war, was zu inkonsistenten Verhaltensweisen innerhalb von Create/Drop-Sequenzen führte.

  Referenzen: #11802

typing

• [typing] [fehler]

  Tippfehler mit Select.with_only_columns() behoben.

  Referenzen: #11782

postgresql

• [postgresql] [fehler]

  Kritischer Fehler im asyncpg-Treiber behoben, bei dem ein Rollback oder Commit, das speziell für die Bedingung MissingGreenlet oder einen anderen Fehler, der nicht von asyncpg selbst ausgelöst wird, fehlschlägt, die asyncpg-Transaktion in jedem Fall verwirft, obwohl die Transaktion noch idle war, was zu einem serverseitigen Zustand mit einer idle Transaktion führte, die dann zurück in den Connection-Pool gelangte. Die Flags für „Transaktion geschlossen“ werden nun für Fehler, die außerhalb von asyncpg selbst auftreten, nicht zurückgesetzt. Wenn asyncpg selbst einen Fehler für .commit() oder .rollback() auslöst, verwirft asyncpg diese Transaktion dann.

  Diese Änderung wird auch zurückportiert nach: 1.4.54

  Referenzen: #11819

• [postgresql] [fehler]

  Überarbeitung der Asyncpg-Korrektur terminate(), die erstmals in #10717 vorgenommen wurde und die Ausfallsicherheit dieses Aufrufs unter allen Umständen verbesserte. asyncio.CancelledError wurde zur Liste der Ausnahmen hinzugefügt, die als Fehler für ein ordnungsgemäßes .close() abgefangen werden, welches dann .terminate() aufruft.

  Referenzen: #11821

mysql

• [mysql] [fehler]

  Problem im MySQL-Dialekt behoben, bei dem die Verwendung von INSERT..FROM SELECT in Kombination mit ON DUPLICATE KEY UPDATE auf MySQL 8 und höher fälschlicherweise die Klausel „AS new“ rendert, was zu Syntaxfehlern führt. Diese Klausel ist auf MySQL 8 erforderlich, um der VALUES-Klausel zu folgen, wenn der Alias „new“ verwendet wird, ist aber nicht zulässig, einer FROM SELECT-Klausel zu folgen.

  Referenzen: #11731

sqlite

• [sqlite] [fehler]

  Verbesserungen am Regex des SQLite-Dialekts zur Reflexion des Namens und Inhalts eines CHECK-Constraints. Constraints mit Zeilenumbrüchen, Tabs oder Leerzeichen in sowohl dem Constraint-Text als auch dem Constraint-Namen werden nun korrekt reflektiert. Pull-Request von Jeff Horemans.

  Referenzen: #11677

• [sqlite] [fehler]

  Verbesserungen am Regex des SQLite-Dialekts zur Reflexion des Namens und Inhalts eines UNIQUE-Constraints, der inline innerhalb einer Spaltendefinition in einer SQLite CREATE TABLE-Anweisung definiert ist, unter Berücksichtigung von Tabulatorzeichen innerhalb der Spalten-/Constraint-Zeile. Pull-Request von John A Stevenson.

  Referenzen: #11746

mssql

• [mssql] [fehler]

  Fehler „The server failed to resume the transaction“ zur Liste der Fehlermeldungen für den pymssql-Treiber hinzugefügt, um ein Trennungsszenario zu ermitteln. Dies wurde von einem Benutzer beobachtet, der pymssql unter sonst unbekannten Bedingungen verwendete, da eine unbrauchbare Verbindung im Connection-Pool verblieb, die nicht ordnungsgemäß gepingt werden konnte.

  Referenzen: #11822

tests

• [tests] [fehler]

  Fehlendes array_type-Attribut zur Testsuite-Klasse SuiteRequirements hinzugefügt.

2.0.32

Veröffentlicht: 5. August 2024

general

• [general] [fehler] [regression]

  Alte Klassennamen aus sqlalalchemy.orm.collections.* wiederhergestellt, einschließlich MappedCollection, mapped_collection(), column_mapped_collection(), attribute_mapped_collection(). Pull-Request von Takashi Kajinami.

  Referenzen: #11435

orm

• [orm] [anwendungsfall]

  Der Parameter aliased.name für aliased() kann nun mit dem Parameter aliased.flat kombiniert werden, was tabellenbezogene Namen basierend auf einer Namenspräfix-Konvention erzeugt. Pull Request von Eric Atkin.

  Referenzen: #11575

• [orm] [bug] [regression]

  Behobene Regression seit 1.4, 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 der erwarteten NoResultFound, die in 1.3 auftrat.

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

  Referenzen: #11562

• [orm] [bug]

  Behobenes Problem, bei dem die Methoden Query.enable_eagerloads() und Query.yield_per() gleichzeitig verwendet wurden, um das direkt auf dem Mapper konfigurierte Eager Loading zu deaktivieren, diese ignoriert wurden, was zu Fehlern oder unerwarteter Eager-Befüllung von Attributen führte.

  Referenzen: #10834

• [orm] [bug] [regression]

  Behobene Regression, die in 2.0.21 aufgrund von #10279 auftrat, bei der die Verwendung von delete() oder update() auf eine ORM-Klasse, die die Basis einer Vererbungshierarchie ist, während gleichzeitig spezifiziert wird, dass Unterklassen polymorph geladen werden sollen, die polymorphen Joins in die UPDATE- oder DELETE-Anweisung leckte und falsche SQL erzeugte.

  Referenzen: #11625

• [orm] [bug] [regression]

  Behobene Regression seit Version 1.4 in Session.bulk_insert_mappings(), bei der die Verwendung des Parameters Session.bulk_insert_mappings.return_defaults die übergebenen Dictionaries nicht mit neu generierten Primärschlüsselwerten befüllte.

  Referenzen: #11661

• [orm]

  Warnung hinzugefügt, die darauf hinweist, wenn ein ConnectionEvents.engine_connect() Ereignis eine Transaktion offen lässt, was das Verhalten einer Session, die eine solche Engine als Bindung verwendet, ändern kann. Auf SQLAlchemy 2.1 wird Session.join_transaction_mode stattdessen in allen Fällen ignoriert, wenn die Session-Bindung eine Engine ist.

  Referenzen: #11163

examples

• [examples] [bug]

  Behobenes Problem im history_meta-Beispiel, bei dem die „version“-Spalte in der versionierten Tabelle beim INSERT standardmäßig die neueste Versionsnummer in der Verlaufstabelle haben muss, um dem Anwendungsfall einer Tabelle gerecht zu werden, bei der Zeilen gelöscht und dann durch neue Zeilen ersetzt werden, die dieselbe Primärschlüssel-Identität wiederverwenden. Diese Korrektur fügt pro INSERT eine zusätzliche SELECT-Abfrage in der Haupttabelle hinzu, was ineffizient sein kann; für Fälle, in denen Primärschlüssel nicht wiederverwendet werden, kann die Standardfunktion weggelassen werden. Patch von Philipp H. v. Loewenfeld.

  Referenzen: #10267

engine

• [engine] [bug]

  Behobenes Problem bei der „insertmanyvalues“-Funktion, bei der ein bestimmter Aufruf von cursor.fetchall() nicht in die Ausnahmebehandlung von SQLAlchemy eingeschlossen war, was anscheinend eine Datenbankausnahme während des Abrufs auslösen kann, wenn pyodbc verwendet wird.

  Referenzen: #11532

sql

• [sql] [bug]

  Nachverfolgung von #11471 zur Behebung eines Caching-Problems, bei dem die Verwendung der Methode CompoundSelectState.add_cte() des CompoundSelectState Konstrukts keinen korrekten Cache-Schlüssel gesetzt hat, der zwischen verschiedenen CTE-Ausdrücken unterschieden hätte. Außerdem wurden Tests hinzugefügt, die Probleme ähnlich dem in #11544 behobenen erkennen.

  Referenzen: #11471

• [sql] [bug]

  Behobener Fehler, bei dem die Modifikatoren Operators.nulls_first() und Operators.nulls_last() nicht auf die gleiche Weise wie Operators.desc() und Operators.asc() behandelt wurden, wenn bestimmt wurde, ob eine ORDER BY-Klausel gegen einen bereits in der Anweisung vorhandenen Label-Namen erfolgt. Alle vier Modifikatoren werden nun innerhalb von ORDER BY gleich behandelt.

  Referenzen: #11592

schema

• [schema] [bug]

  Weitere Probleme im Ereignissystem behoben, die durch das Entpickeln eines Enum-Datentyps ausgelöst wurden, fortsetzend von #11365 und #11360, bei denen dynamisch generierte Elemente der Ereignisstruktur beim Entpickeln in einem neuen Prozess nicht vorhanden waren.

  Referenzen: #11530

typing

• [typing] [bug]

  Interne Typisierungsprobleme behoben, um die Kompatibilität mit mypy 1.11.0 herzustellen. Beachten Sie, dass dies keine Probleme einschließt, die mit dem veralteten mypy-Plugin für SQLAlchemy 1.4-Code aufgetreten sind. Siehe die zusätzliche Änderungsnotiz für dieses Plugin, die die überarbeitete Kompatibilität angibt.

mypy

• [mypy] [bug]

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

  Siehe auch

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

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

postgresql

• [postgresql] [bug]

  Ein „SSL SYSCALL error: Success“-Fehler, der bei abnormaler Beendigung der SSL-Verbindung zu Postgres auftreten kann, wird nun als Pool-ungültiger Trennungsereignis betrachtet.

  Referenzen: #11522

• [postgresql] [bug]

  Behobenes Problem, bei dem der collate()-Konstrukt, das explizit eine Sortierung für einen gegebenen Ausdruck festlegt, die Sortierungseinstellungen für das zugrundeliegende Typobjekt aus dem Ausdruck beibehielt, was dazu führte, dass SQL-Ausdrücke doppelte Sortierungen enthielten, wenn sie in weiteren Ausdrücken für bestimmte Dialekte verwendet wurden, die explizite Typumwandlungen rendern, wie z. B. asyncpg. Das collate()-Konstrukt weist nun seinen eigenen Typ zu, um die neue Sortierung explizit einzuschließen, vorausgesetzt, es handelt sich um einen Zeilentyp.

  Referenzen: #11576

mysql

• [mysql] [bug]

  Behobenes Problem im MySQL-Dialekt, bei dem ENUM-Werte, die Prozentzeichen enthielten, nicht ordnungsgemäß für den Treiber escaped wurden.

  Referenzen: #11479

sqlite

• [sqlite] [bug] [reflection]

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

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

  Referenzen: #11582

mssql

• [mssql] [bug]

  Behobenes Problem, bei dem SQL Server-Treiber keine gebundenen Parameter beim Rendern der „Frame-Spezifikation“ für eine Fensterfunktion wie „ROWS BETWEEN“ usw. unterstützen.

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

  Referenzen: #11514

oracle

• [oracle] [usecase]

  API-Unterstützung für serverseitige Cursor für den asynchronen oracledb-Dialekt hinzugefügt, wodurch die Verwendung von AsyncConnection.stream() und ähnlichen Stream-Methoden ermöglicht wird.

  Referenzen: #10820

• [oracle] [usecase]

  Implementierung von Zwei-Phasen-Transaktionen für den oracledb-Dialekt. Historisch gesehen funktionierte diese Funktion nie mit dem cx_Oracle-Dialekt, aber jüngste Verbesserungen des oracledb-Nachfolgers machen dies nun möglich. Die Zwei-Phasen-Transaktions-API ist auf Core-Ebene über die Methode Connection.begin_twophase() verfügbar.

  Referenzen: #11480

• [oracle] [bug]

  Behobene Tabellenreflexion auf Oracle 10.2 und älter, wo Kompressionsoptionen nicht unterstützt wurden.

  Referenzen: #11557

• [oracle] [bug] [sqlite]

  Implementierung von bitweisen Operatoren für Oracle, die zuvor aufgrund einer nicht standardmäßigen Syntax dieser Datenbank nicht funktionierten. Oracles Unterstützung für bitweises „oder“ und „xor“ beginnt mit Serverversion 21. Außerdem wurde die Implementierung von „xor“ für SQLite repariert.

  Als Teil dieser Änderung wurde die Testsuite für die Dialektkonformität um die Unterstützung für serverseitige bitweise Tests erweitert. Drittanbieter-Dialekt-Autoren sollten sich auf die neuen Methoden „supports_bitwise“ in der Datei requirements.py beziehen, um diese Tests zu aktivieren.

  Referenzen: #11663

2.0.31

Veröffentlicht: 18. Juni 2024

general

• [general] [bug]

  Vollständige Python 3.13-Unterstützung im weitestgehenden möglichen Umfang eingerichtet, wobei Probleme in internen Sprachhelfern sowie im Serialisierungs-Erweiterungsmodul behoben wurden.

  Für Version 1.4 werden auch die „extras“-Namen in setup.cfg modernisiert, um Bindestriche und keine Unterstriche für zweistellige Namen zu verwenden. Unterstrichene Namen sind weiterhin vorhanden, um potenzielle Kompatibilitätsprobleme zu berücksichtigen.

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

  Referenzen: #11417

• [general] [bug]

  Vollständige Python 3.13-Unterstützung im weitestgehenden möglichen Umfang eingerichtet, wobei Probleme in internen Sprachhelfern sowie im Serialisierungs-Erweiterungsmodul behoben wurden.

  Referenzen: #11417

orm

• [orm] [usecase]

  Fehlender Parameter with_polymorphic.name hinzugefügt, der die Benennung der zurückgegebenen AliasedClass ermöglicht.

  Referenzen: #11361

• [orm] [bug]

  Behobenes Problem, bei dem eine MetaData-Sammlung nicht serialisierbar war, wenn ein Enum- oder Boolean-Datentyp vorhanden war, der angepasst worden war. Dieses spezifische Szenario konnte wiederum auftreten, wenn Enum oder Boolean innerhalb der ORM Annotated Declarative Form verwendet wurden, wo Typobjekte häufig kopiert werden.

  Referenzen: #11365

• [orm] [bug]

  Behobenes Problem, bei dem die Loader-Optionen selectinload() und subqueryload() keine Wirkung zeigten, wenn sie auf eine geerbte Unterklasse angewendet wurden, die selbst eine unterklassenspezifische Mapper.with_polymorphic-Einstellung enthielt.

  Referenzen: #11446

• [orm] [bug]

  Behobenes sehr altes Problem mit dem Parameter joinedload.innerjoin, bei dem die Verwendung dieses Parameters in einer Abfrage, die auch joined eager loads entlang einer selbstreferenziellen oder anderen zyklischen Beziehung enthielt, zusammen mit komplizierenden Faktoren wie inner joins für Sekundärtabellen usw., die Chance hatte, einen bestimmten inner join an die falsche Stelle der Abfrage einzufügen. Zusätzlicher Zustand wurde in die interne Methode, die diese Einfügung vornimmt, aufgenommen, um eine bessere Entscheidung darüber zu treffen, wo die Einfügung erfolgen soll.

  Referenzen: #11449

• [orm] [bug] [regression]

  Behobener Fehler in ORM Declarative, bei dem die Direktive __table__ nicht als Klassenfunktion mit declared_attr() auf einer Oberklasse, einschließlich einer __abstract__-Klasse sowie der deklarativen Basis selbst, deklariert werden konnte. Dies war eine Regression seit 1.4, wo dies funktionierte, und es gab anscheinend keine Tests für diesen speziellen Anwendungsfall.

  Referenzen: #11509

engine

• [engine] [usecase]

  Die interne Darstellung zur 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, erlaubt direkte Aufrufe an sqlalchemy.util.await_only().

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

sql

• [sql] [bug]

  Behobenes Caching-Problem, bei dem die Verwendung der Methode TextualSelect.add_cte() des TextualSelect Konstrukts keinen korrekten Cache-Schlüssel gesetzt hat, der zwischen verschiedenen CTE-Ausdrücken unterschieden hätte.

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

  Referenzen: #11471

• [sql] [bug]

  Behobenes Problem beim Serialisieren einer over()-Klausel mit unbegrenztem Bereich oder Zeilen.

  Referenzen: #11422

• [sql] [bug]

  Fehlende Methoden FunctionFilter.within_group() und WithinGroup.filter() hinzugefügt

  Referenzen: #11423

• [sql] [bug]

  Behobener Fehler in FunctionFilter.filter(), der die vorhandene Funktion inplace mutierte. Sie verhält sich nun wie der Rest der SQLAlchemy-API und gibt eine neue Instanz zurück, anstatt die ursprüngliche zu mutieren.

  Referenzen: #11426

schema

• [schema] [usecase]

  Column.insert_default als Alias von Column.default für Kompatibilität mit mapped_column() hinzugefügt.

  Referenzen: #11374

mysql

• [mysql] [usecase] [reflection]

  Fehlende Fremdschlüssel-Reflexionsoption SET DEFAULT in den MySQL- und MariaDB-Dialekten hinzugefügt. Pull Request von Quentin Roche.

  Referenzen: #11285

2.0.30

Veröffentlicht: 5. Mai 2024

orm

• [orm] [bug]

  Neues Attribut ORMExecuteState.is_from_statement hinzugefügt, um Anweisungen zu erkennen, die mit Select.from_statement() erstellt wurden, und FromStatement erweitert, um ORMExecuteState.is_select, ORMExecuteState.is_insert, ORMExecuteState.is_update und ORMExecuteState.is_delete entsprechend dem Element zu setzen, das an die Methode Select.from_statement() übergeben wird.

  Referenzen: #11220

• [orm] [bug]

  Behobenes Problem in der Loader-Option selectin_polymorphic(), bei der Attribute, die mit composite() auf einer Oberklasse definiert wurden, beim Laden einen internen Fehler verursachten.

  Referenzen: #11291

• [orm] [bug] [regression]

  Behobene Regression seit 1.4, bei der die Verwendung von defaultload() in Verbindung mit einem nicht propagierenden Loader wie contains_eager() dennoch die contains_eager() für eine Lazy-Load-Operation propagierte, was zu fehlerhaften Abfragen führte, da diese Option nur von einer ursprünglichen Ladung stammen sollte.

  Referenzen: #11292

• [orm] [bug]

  Behobenes Problem in ORM Annotated Declarative, bei dem ein Tippfehler dazu führte, dass Literale, die mit PEP 695 Typ-Aliassen definiert wurden, nicht mit der Inferenz von Enum-Datentypen funktionierten. Pull Request von Alc-Alc.

  Referenzen: #11305

• [orm] [bug]

  Behobenes Problem bei der selectin_polymorphic() Ladeoption, bei der die generierte SELECT-Anweisung nur für die unterste Klasse unter den zurückgegebenen Ergebniszeilen Platz bot. Dies führte dazu, dass Attribute von Zwischenklassen entladen wurden, wenn keine konkreten Instanzen dieser Zwischenklasse im Ergebnis vorhanden waren. Dieses Problem trat nur bei mehrstufigen Vererbungshierarchien auf.

  Referenzen: #11327

• [orm] [bug]

  Behobenes Problem bei Session.bulk_save_objects(), bei dem die Form des Identitätsschlüssels bei Verwendung von return_defaults=True inkorrekt war. Dies konnte zu Fehlern beim Pickling sowie zu Abweichungen in der Identitätszuordnung führen.

  Referenzen: #11332

• [orm] [bug]

  Behobenes Problem, bei dem die Attributschlüsselnamen in Bundle bei Verwendung von ORM-aktiviertem select im Gegensatz zu Query nicht korrekt waren, wenn die Anweisung doppelte Spaltennamen enthielt.

  Referenzen: #11347

engine

• [engine] [bug]

  Behobenes Problem bei der Option Connection.execution_options.logging_token, bei der das Ändern des Werts von logging_token bei einer Verbindung, die bereits Nachrichten protokolliert hatte, nicht aktualisiert wurde, um den neuen Protokollierungstoken widerzuspiegeln. Dies verhinderte insbesondere die Verwendung von Session.connection() zum Ändern der Option bei der Verbindung, da die BEGIN-Protokollierungsnachricht bereits ausgegeben worden war.

  Referenzen: #11210

• [engine] [bug]

  Behobenes Problem bei der Cursor-Behandlung, das die Behandlung von doppelten Column oder ähnlichen Objekten in der Spaltenklausel von select() betraf, sowohl in Kombination mit beliebigen text()-Klauseln in der SELECT-Liste als auch beim Versuch, Result.mappings() für das Objekt abzurufen, was zu einem internen Fehler geführt hätte.

  Referenzen: #11306

typing

• [typing] [bug] [regression]

  Behobene Tippfehler-Regression, die durch #11055 in Version 2.0.29 verursacht wurde. Diese fügte ParamSpec zu den run_sync()-Methoden für asyncio hinzu, was bei Verwendung von AsyncConnection.run_sync() mit MetaData.reflect() zu einem Fehler bei mypy führte, aufgrund eines mypy-Problems. Pull Request von Francisco R. Del Roio.

  Referenzen: #11200

• [typing] [bug]

  Behobenes Problem bei der Typisierung von Bundle, bei dem die Erstellung einer verschachtelten Bundle-Struktur nicht erlaubt war.

misc

• [bug] [test]

  Sichergestellt, dass die Variable PYTHONPATH korrekt initialisiert wird, wenn subprocess.run in den Tests verwendet wird.

  Referenzen: #11268

• [bug] [installation]

  Behobene interne Klasse, die auf unerwartete Attribute prüfte, um unter dem kommenden Python 3.13 korrekt zu funktionieren. Pull Request von Edgar Ramírez-Mondragón.

  Referenzen: #11334

2.0.29

Veröffentlicht: 23. März 2024

orm

• [orm] [usecase]

  Unterstützung für den PEP 695 TypeAliasType-Konstrukt sowie das native Python 3.12 type-Schlüsselwort hinzugefügt, um mit der ORM Annotated Declarative Form zu arbeiten. Dies ermöglicht die Verknüpfung mit einem PEP 593 Annotated-Container, was die Auflösung von Annotated ermöglicht, wenn diese Konstrukte in einem Mapped-Typcontainer verwendet werden.

  Referenzen: #11130

• [orm] [bug]

  Behobenes Deklarationsproblem, bei dem die Typisierung einer Beziehung mit Relationship anstelle von Mapped unbeabsichtigt die "dynamische" Beziehungs-Ladefunktion für dieses Attribut zog.

  Referenzen: #10611

• [orm] [bug]

  Behobenes Problem bei ORM-annotierter Deklaration, bei dem die Verwendung von mapped_column() mit einer Einstellung von mapped_column.index oder mapped_column.unique auf False durch ein eingehendes Annotated-Element überschrieben wurde, das diesen Parameter auf True gesetzt hatte, obwohl das unmittelbare mapped_column()-Element spezifischer ist und Vorrang haben sollte. Die Logik zur Abgleichung der Booleans wurde verbessert, um einem lokalen Wert von False Vorrang vor einem eingehenden True-Wert aus dem annotierten Element zu geben.

  Referenzen: #11091

• [orm] [bug] [regression]

  Behobene Regression aus Version 2.0.28, die durch die Behebung von #11085 verursacht wurde, bei der die neuere Methode zur Anpassung von nach dem Cache gebundenen Parameterwerten die Implementierung für die subqueryload() Ladeoption beeinträchtigte. Diese hatte einige ältere Muster intern in Verwendung, wenn die zusätzlichen Lade-Kriterien-Features mit dieser Ladeoption verwendet wurden.

  Referenzen: #11173

engine

• [engine] [bug]

  Behobenes Problem bei der Funktion "Insert Many Values"-Verhalten für INSERT-Anweisungen, bei der die Verwendung einer Primärschlüsselspalte mit einem "Inline Execute"-Standardgenerator wie einer expliziten Sequence mit einem expliziten Schemanamen, während gleichzeitig die Funktion Connection.execution_options.schema_translate_map verwendet wurde, dazu führte, dass die Sequenz oder die Parameter nicht richtig gerendert wurden, was zu Fehlern führte.

  Referenzen: #11157

• [engine] [bug]

  Änderung der in Version 2.0.10 vorgenommenen Anpassung für #9618, die das Verhalten der Abgleichung von RETURNING-Zeilen von einem Massen-INSERT mit den übergebenen Parametern hinzufügte. Dieses Verhalten beinhaltete einen Vergleich von bereits von der Datenbank konvertierten gebundenen Parameterwerten mit zurückgegebenen Zeilenwerten, der nicht immer "symmetrisch" für SQL-Spaltentypen wie UUIDs war, abhängig von den spezifischen Details, wie verschiedene DBAPIs solche Werte empfangen im Vergleich dazu, wie sie sie zurückgeben. Dies erforderte die Notwendigkeit zusätzlicher "Sentinel-Wert-Resolver"-Methoden für diese Spaltentypen. Leider brach dies Drittanbieter-Spaltentypen wie UUID/GUID-Typen in Bibliotheken wie SQLModel, die diese spezielle Methode nicht implementierten, und löste den Fehler "Can’t match sentinel values in result set to parameter sets" aus. Anstatt zu versuchen, dieses Implementierungsdetail der "insertmanyvalues"-Funktion weiter zu erklären und zu dokumentieren, einschließlich einer öffentlichen Version der neuen Methode, wird der Ansatz stattdessen überarbeitet, sodass dieser zusätzliche Konvertierungsschritt nicht mehr erforderlich ist. Die Logik, die den Vergleich durchführt, arbeitet nun mit dem vor der Konvertierung gebundenen Parameterwert im Vergleich zum nach der Verarbeitung des Ergebnisses stehenden Wert, der immer vom gleichen Datentyp sein sollte. In dem ungewöhnlichen Fall, dass ein benutzerdefinierter SQL-Spaltentyp, der zufällig auch in einer "Sentinel"-Spalte für Massen-INSERT verwendet wird, nicht denselben Werttyp empfängt und zurückgibt, wird der Fehler "Can’t match" ausgelöst. Die Abhilfe ist jedoch einfach: derselbe Python-Datentyp sollte als der zurückgegebene übergeben werden.

  Referenzen: #11160

sql

• [sql] [bug] [regression]

  Behobene Regression aus der 1.4-Serie, bei der die Umstrukturierung der Methode TypeEngine.with_variant(), die unter „with_variant()“ klont die ursprüngliche TypeEngine anstelle des Änderns des Typs eingeführt wurde, die Methode .copy() nicht berücksichtigte, was die eingerichteten Variantenzuordnungen verlieren würde. Dies wird zu einem Problem für den sehr spezifischen Fall eines "Schema"-Typs, der Typen wie Enum und ARRAY umfasst, wenn sie dann im Kontext einer ORM Declarative-Zuordnung mit Mixins verwendet werden, bei denen das Kopieren von Typen eine Rolle spielt. Die Variantenzuordnung wird nun ebenfalls kopiert.

  Referenzen: #11176

typing

• [typing] [bug]

  Behobenes Tippfehlerproblem, das es den run_sync()-Methoden von asyncio ermöglicht, die Parameter entsprechend dem übergebenen Callable korrekt zu typisieren, indem PEP 612 ParamSpec-Variablen verwendet werden. Pull Request von Francisco R. Del Roio.

  Referenzen: #11055

postgresql

• [postgresql] [usecase]

  Das PostgreSQL-Dialekt gibt nun DOMAIN-Instanzen zurück, wenn eine Spalte mit einem Domänentyp reflektiert wird. Zuvor wurde der Domänen-Datentyp zurückgegeben. Als Teil dieser Änderung wurde die Domänenreflexion verbessert, um auch die Kollation der Texttypen zurückzugeben. Pull Request von Thomas Stephenson.

  Referenzen: #10693

tests

• [tests] [bug]

  Zurückportierung einer Verbesserung der Testsuite auf SQLAlchemy 2.0 bezüglich der Ausführung von asyncio-bezogenen Tests. Nun wird der neuere Python 3.11 asyncio.Runner oder ein zurückportiertes Äquivalent verwendet, anstatt sich auf die vorherige Implementierung basierend auf asyncio.get_running_loop() zu verlassen. Dies soll hoffentlich Probleme bei großen Testlauf-Suiten auf CPU-belasteter Hardware verhindern, bei denen die Ereignisschleife beschädigt zu werden scheint, was zu kaskadierenden Fehlern führt.

  Referenzen: #11187

2.0.28

Veröffentlicht: 4. März 2024

orm

• [orm] [bug] [regression]

  Behobene Regression, die durch #9779 verursacht wurde, bei der die Verwendung der "sekundären" Tabelle in einem Beziehungs-Ausdruck and_() fehlschlug, diese zu aliasieren, um sie an die Art und Weise anzupassen, wie die "sekundäre" Tabelle normalerweise in einem Select.join()-Ausdruck gerendert wird, was zu einer ungültigen Abfrage führte.

  Referenzen: #11010

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

  Angepasste Korrektur aus #10570, veröffentlicht in 2.0.23, bei der neue Logik zur Abgleichung möglicherweise sich ändernder gebundener Parameterwerte über Cache-Schlüssel-Generationen hinweg hinzugefügt wurde, die innerhalb des with_expression()-Konstrukts verwendet werden. Die neue Logik ändert den Ansatz, wie die neuen gebundenen Parameterwerte der Anweisung zugeordnet werden, und vermeidet die Notwendigkeit, die Anweisung tief zu kopieren, was zu einer erheblichen Leistungsbeeinträchtigung bei sehr tiefen/komplexen SQL-Konstrukten führen kann. Der neue Ansatz erfordert diesen Schritt des tiefen Kopierens nicht mehr.

  Referenzen: #11085

engine

• [engine] [usecase]

  Neue Kern-Ausführungsoption Connection.execution_options.preserve_rowcount hinzugefügt. Wenn diese gesetzt ist, wird das Attribut cursor.rowcount des DBAPI-Cursors bei der Anweisungsausführung bedingungslos gespeichert, so dass der vom DBAPI für jede Art von Anweisung angebotene Wert über das Attribut CursorResult.rowcount des CursorResult verfügbar ist. Dies ermöglicht den Zugriff auf rowcount für Anweisungen wie INSERT und SELECT, soweit dies vom verwendeten DBAPI unterstützt wird. Das "Insert Many Values"-Verhalten für INSERT-Anweisungen unterstützt ebenfalls diese Option und stellt sicher, dass CursorResult.rowcount für einen Massen-INSERT von Zeilen korrekt gesetzt wird, wenn diese Option gesetzt ist.

  Referenzen: #10974

asyncio

• [asyncio] [bug]

  Es wird ein Fehler ausgelöst, wenn eine QueuePool oder eine andere nicht-asyncio-Poolklasse an create_async_engine() übergeben wird. Diese Engine akzeptiert nur asyncio-kompatible Poolklassen, einschließlich AsyncAdaptedQueuePool. Andere Poolklassen wie NullPool sind sowohl mit synchronen als auch mit asynchronen Engines kompatibel, da sie keine Sperren durchführen.

  Siehe auch

  API-Dokumentation - Verfügbare Pool-Implementierungen

  Referenzen: #8771

tests

• [tests] [change]

  Die Pytest-Unterstützung in der Datei tox.ini wurde aktualisiert, um Pytest 8.1 zu unterstützen.

2.0.27

Veröffentlicht: 13. Februar 2024

postgresql

• [postgresql] [bug] [regression]

  Behobene Regression, die durch die gerade veröffentlichte Korrektur für #10863 verursacht wurde, bei der eine ungültige Ausnahmeklasse zum "except"-Block hinzugefügt wurde, die nicht ausgeführt wird, es sei denn, ein solcher Catch tritt tatsächlich ein. Ein Mock-ähnlicher Test wurde hinzugefügt, um sicherzustellen, dass dieser Catch in den Unit-Tests ausgeführt wird.

  Referenzen: #11005

2.0.26

Veröffentlicht: 11. Februar 2024

orm

• [orm] [bug]

  Die Warnung "loader depth is excessively deep" (Ladetiefe ist exzessiv tief) wurde durch eine kürzere Meldung ersetzt, die dem Caching-Badge innerhalb der SQL-Protokollierung hinzugefügt wird, für Anweisungen, bei denen das ORM den Cache aufgrund einer zu tiefen Kette von Ladeoptionen deaktiviert hat. Die Bedingung, die diese Warnung hervorhebt, ist schwer zu beheben und stellt im Allgemeinen nur eine Einschränkung der ORM-Anwendung des SQL-Cachings dar. Eine zukünftige Funktion könnte die Möglichkeit bieten, den Schwellenwert für die Deaktivierung des Cachings einzustellen, aber vorerst wird die Warnung keine Belästigung mehr darstellen.

  Referenzen: #10896

• [orm] [bug]

  Behobenes Problem, bei dem es nicht möglich war, einen Typ (wie z. B. ein Enum) innerhalb eines Mapped-Container-Typs zu verwenden, wenn dieser Typ lokal innerhalb des Klassenkörpers deklariert wurde. Der Gültigkeitsbereich der für die Auswertung verwendeten lokalen Variablen umfasst nun den Klassenkörper selbst. Darüber hinaus kann der Ausdruck innerhalb von Mapped auf den Klassennamen selbst verweisen, wenn er als Zeichenkette oder im Modus für zukünftige Annotationen verwendet wird.

  Referenzen: #10899

• [orm] [bug]

  Behobenes Problem, bei dem die Verwendung von Session.delete() zusammen mit der Funktion Mapper.version_id_col dazu führte, dass der korrekte Versionsidentifikator nicht verwendet wurde, falls eine zusätzliche UPDATE-Anweisung gegen das Zielobjekt gesendet wurde, als Ergebnis der Verwendung von relationship.post_update auf dem Objekt. Das Problem ist ähnlich zu #10800, das gerade in Version 2.0.25 für den Fall von reinen Updates behoben wurde.

  Referenzen: #10967

• [orm] [bug]

  Behobenes Problem, bei dem eine Assertion innerhalb der Implementierung für with_expression() ausgelöst wurde, wenn ein nicht-cachebarer SQL-Ausdruck verwendet wurde; dies war eine 2.0-Regression seit 1.4.

  Referenzen: #10990

examples

• [examples] [bug]

  Behobene Regression im Beispiel history_meta, bei der die Verwendung von MetaData.to_metadata() zum Kopieren der Verlaufstabelle auch Indizes kopierte (was gut ist), aber Namenskonflikte verursachte, unabhängig vom verwendeten Benennungsschema für diese Indizes. Ein "_history"-Suffix wird nun zu diesen Indizes hinzugefügt, genauso wie es für den Tabellennamen geschieht.

  Referenzen: #10920

• [examples] [bug]

  Behobene Performance-Beispielskripte in examples/performance, damit sie größtenteils mit der Oracle-Datenbank funktionieren. Hierzu wurde das Konstrukt Identity zu allen Tabellen hinzugefügt und die Primärgenerierung auf diesem Backend erlaubt. Einige der "rohen DBAPI"-Fälle sind mit Oracle immer noch nicht kompatibel.

sql

• [sql] [bug]

  Behobene Probleme mit case(), bei denen die Logik zur Bestimmung des Typs des Ausdrucks zu NullType führen konnte, wenn das letzte Element in den "whens" keinen Typ hatte, oder in anderen Fällen, in denen der Typ zu None aufgelöst werden konnte. Die Logik wurde aktualisiert, um alle gegebenen Ausdrücke zu scannen, so dass der erste Nicht-Null-Typ verwendet wird, sowie um immer sicherzustellen, dass ein Typ vorhanden ist. Pull Request von David Evans.

  Referenzen: #10843

typing

• [typing] [bug]

  behoben: Typsignatur für das Ereignis PoolEvents.checkin() korrigiert, um anzuzeigen, dass das übergebene DBAPIConnection Argument im Falle einer ungültigen Verbindung None sein kann.

postgresql

• [postgresql] [usecase] [reflection]

  Unterstützung für die Reflexion von PostgreSQL CHECK-Constraints mit „NO INHERIT“ hinzugefügt. Der Schlüssel no_inherit=True wird in den reflektierten Daten gesetzt. Pull-Request von Ellis Valentiner.

  Referenzen: #10777

• [postgresql] [usecase]

  Unterstützung für die Option USING <method> für PostgreSQL CREATE TABLE hinzugefügt, um die Zugriffsmethode für die Speicherung der Inhalte der neuen Tabelle anzugeben. Pull-Request von Edgar Ramírez-Mondragón.

  Siehe auch

  PostgreSQL-Tabellenoptionen

  Referenzen: #10904

• [postgresql] [usecase]

  PostgreSQL RANGE- und MULTIRANGE-Typen werden korrekt als Range[T] und Sequence[Range[T]] typisiert. Die Hilfssequenz MultiRange wurde eingeführt, um die Interoperabilität von MULTIRANGE-Typen zu verbessern.

  Referenzen: #9736

• [postgresql] [usecase]

  Bei der Ableitung des Datenbanktyps aus einer Range- oder MultiRange-Instanz wird nun zwischen INT4- und INT8-Bereichs- und Mehrbereichstypen unterschieden, wobei INT4 bevorzugt wird, wenn die Werte hineinpassen.

• [postgresql] [bug] [regression]

  Regression im asyncpg-Dialekt behoben, die durch #10717 in Version 2.0.24 verursacht wurde. Die Änderung, die nun versucht, die asyncpg-Verbindung vor dem Beenden ordnungsgemäß zu schließen, fiel für andere mögliche verbindungsbezogene Ausnahmen als einen Timeout-Fehler nicht auf terminate() zurück, wobei Fälle, in denen der ordnungsgemäße .close()-Versuch aus anderen Gründen wie Verbindungsfehlern fehlschlägt, nicht berücksichtigt wurden.

  Referenzen: #10863

• [postgresql] [bug]

  Ein Problem im Zusammenhang mit der Verwendung des Uuid-Datentyps mit dem Parameter Uuid.as_uuid auf False gesetzt, bei Verwendung von PostgreSQL-Dialekten, behoben. ORM-optimierte INSERT-Anweisungen (z. B. die Funktion „insertmanyvalues“) richteten UUID-Primärschlüsselwerte für Bulk-INSERT-Anweisungen nicht korrekt aus, was zu Fehlern führte. Ähnliche Probleme wurden auch für den pymssql-Treiber behoben.

mysql

• [mysql] [bug]

  Behoben, dass NULL/NOT NULL nicht ordnungsgemäß von einer MySQL-Spalte reflektiert wurde, die auch die Direktiven VIRTUAL oder STORED angab. Pull-Request von Georg Wicke-Arndt.

  Referenzen: #10850

• [mysql] [bug]

  Behoben, dass die .close()-Methode in den Asyncio-Dialekten asyncmy und aiomysql offenbar kein ordnungsgemäßes Schließen ist. Ersetzt durch die nicht standardmäßige, awaitable .ensure_closed()-Methode und .close() in den sogenannten „terminate“-Fall verschoben.

  Referenzen: #10893

mssql

• [mssql] [bug]

  Ein Problem im Zusammenhang mit der Verwendung des Uuid-Datentyps mit dem Parameter Uuid.as_uuid auf False gesetzt, bei Verwendung des pymssql-Dialekts, behoben. ORM-optimierte INSERT-Anweisungen (z. B. die Funktion „insertmanyvalues“) richteten UUID-Primärschlüsselwerte für Bulk-INSERT-Anweisungen nicht korrekt aus, was zu Fehlern führte. Ähnliche Probleme wurden auch für die PostgreSQL-Treiber behoben.

oracle

• [oracle] [bug] [performance]

  Die Standard-Arraysize der Oracle-Dialekte wurde geändert, so dass der vom Treiber gesetzte Wert verwendet wird, der zum Zeitpunkt der Erstellung für cx_oracle und oracledb 100 beträgt. Zuvor war der Wert standardmäßig auf 50 gesetzt. Die Einstellung von 50 konnte im Vergleich zur alleinigen Verwendung von cx_oracle/oracledb zum Abrufen vieler Hunderter von Zeilen über langsamere Netzwerke erhebliche Leistungsregressionen verursachen.

  Referenzen: #10877

2.0.25

Veröffentlicht: 2. Januar 2024

orm

• [orm] [usecase]

  Vorläufige Unterstützung für Python 3.12 pep-695 Typ-Alias-Strukturen beim Auflösen benutzerdefinierter Typ-Mappings für ORM Annotated Declarative-Mappings hinzugefügt.

  Referenzen: #10807

• [orm] [bug]

  Behoben, dass die gleichzeitige Verwendung des relationship.post_update-Features mit einer Mapper-Version-ID-Spalte zu einer Situation führen konnte, in der die zweite von der Post-Update-Funktion ausgegebene UPDATE-Anweisung den korrekten Versionsbezeichner nicht nutzte, da angenommen wurde, dass in diesem Flush bereits ein UPDATE ausgegeben wurde, das den Versionszähler bereits erhöht hatte.

  Referenzen: #10800

• [orm] [bug]

  Behoben, dass ORM Annotated Declarative die linke Seite einer Beziehung ohne angegebene Sammlung als uselist=True fehlinterpretierte, wenn der linke Typ als Klasse und nicht als Zeichenkette angegeben wurde, ohne zukünftige Annotationen zu verwenden.

  Referenzen: #10815

sql

• [sql] [bug]

  Kompilierung von any_() / all_() im Kontext einer Negation einer booleschen Vergleichung verbessert. Es wird nun NOT (expr) anstelle der Umkehrung des Gleichheitsoperators zu ungleich gerendert, was eine feinere Steuerung von Negationen für diese untypischen Operatoren ermöglicht.

  Referenzen: #10817

typing

• [typing] [bug]

  Regressionen behoben, die durch Typisierungen im Modul sqlalchemy.sql.functions in Version 2.0.24 als Teil von #6810 verursacht wurden.

  • Weitere Verbesserungen der pep-484-Typisierung, um SQL-Funktionen aus von sqlalchemy.sql.expression.func abgeleiteten Elementen besser mit ORM-gemappten Attributen arbeiten zu lassen (#10801)

  • Die an Funktionen übergebenen Argumenttypen wurden korrigiert, damit Literal-Ausdrücke wie Strings und Integers wieder korrekt interpretiert werden (#10818)

  Referenzen: #10801, #10818

asyncio

• [asyncio] [bug]

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

  Diese Änderung ist auch zurückportiert zu: 1.4.51

  Referenzen: #10813

oracle

• [oracle] [asyncio]

  Unterstützung für python-oracledb im Asyncio-Modus hinzugefügt, unter Verwendung der neu veröffentlichten Version des oracledb DBAPI, die Asyncio-Unterstützung enthält. Für die 2.0-Serie ist dies eine Vorschauversion, bei der die aktuelle Implementierung noch keine Unterstützung für AsyncConnection.stream() enthält. Verbesserte Unterstützung ist für die 2.1-Version von SQLAlchemy geplant.

  Referenzen: #10679

2.0.24

Veröffentlicht: 28. Dezember 2023

orm

• [orm] [bug]

  Eine Korrektur, die erstmals für #3208 in Version 0.9.8 veröffentlicht wurde, verbessert, bei der das interne Verzeichnis von Klassen, das von der Deklaration verwendet wird, bei gleichzeitiger Garbage Collection einzelner gemappter Klassen und Konstruktion neuer gemappter Klassen einem Wettlauf unterliegen konnte, wie es in einigen Testsuiten-Konfigurationen oder dynamischen Klassenerstellungsumgebungen vorkommt. Zusätzlich zur bereits hinzugefügten Weakref-Prüfung wird auch die Liste der iterierten Elemente zuerst kopiert, um Fehler wie „Liste während der Iteration geändert“ zu vermeiden. Pull-Request von Yilei Yang.

  Diese Änderung ist auch zurückportiert zu: 1.4.51

  Referenzen: #10782

• [orm] [bug]

  Behoben, dass die Annotation foreign() auf einem nicht initialisierten mapped_column()-Konstrukt ein Ausdruck ohne Typ erzeugte, der dann zur Initialisierungszeit der tatsächlichen Spalte nicht aktualisiert wurde, was zu Problemen führte, wie z. B. dass Beziehungen use_get nicht richtig bestimmten.

  Referenzen: #10597

• [orm] [bug]

  Fehlermeldung verbessert, die ausgegeben wird, wenn der Unit-of-Work-Prozess den Wert einer Primärschlüsselspalte aufgrund des Löschens eines verknüpften Objekts mit einer Abhängigkeitsregel auf dieser Spalte auf NULL setzt. Die Meldung enthält nun nicht nur das Zielobjekt und den Spaltennamen, sondern auch die Quellspalte, von der der NULL-Wert stammt. Pull-Request von Jan Vollmer.

  Referenzen: #10668

• [orm] [bug]

  Die Methode __init_subclass__(), die von MappedAsDataclass, DeclarativeBase und DeclarativeBaseNoMeta verwendet wird, wurde so geändert, dass sie beliebige **kw akzeptiert und diese an den super()-Aufruf weitergibt. Dies ermöglicht eine größere Flexibilität bei der Anordnung benutzerdefinierter Oberklassen und Mixins, die __init_subclass__()-Schlüsselwortargumente verwenden. Pull-Request von Michael Oliver.

  Referenzen: #10732

• [orm] [bug]

  Der Anwendungsfall von Bundle-Objekten, die im returning()-Teil von ORM-aktivierten INSERT-, UPDATE- und DELETE-Anweisungen verwendet werden, wurde getestet und funktioniert nun vollständig. Dies wurde zuvor nie explizit implementiert oder getestet und funktionierte in der 1.4er-Serie nicht korrekt. In der 2.0er-Serie fehlte eine Implementierungsmethode für ORM UPDATE/DELETE mit WHERE-Kriterien, was die Funktionsweise von Bundle-Objekten verhinderte.

  Referenzen: #10776

• [orm] [bug]

  2.0-Regression in MutableList behoben, bei der eine Routine zur Erkennung von Sequenzen Zeichenketten- oder Byte-Instanzen nicht korrekt herausfilterte, was die Zuweisung eines Zeichenkettenwerts zu einem bestimmten Index unmöglich machte (während Nicht-Sequenzwerte einwandfrei funktionierten).

  Referenzen: #10784

engine

• [engine] [bug]

  URL-Codierung der Benutzername- und Passwortkomponenten von URL-Objekten beim Konvertieren in Zeichenketten mit der Methode URL.render_as_string() korrigiert. Dabei wird die Python-Standardbibliothek urllib.parse.quote verwendet, wobei Pluszeichen und Leerzeichen unverändert bleiben, wie von der nicht standardmäßigen URL-Analyse von SQLAlchemy unterstützt, anstelle der alten, selbst entwickelten Routine von vor vielen Jahren. Pull-Request von Xavier NUNN.

  Referenzen: #10662

sql

• [sql] [bug]

  Fehler in der Stringifizierung für SQL-Elemente behoben, bei dem ein spezifischer Dialekt nicht übergeben wurde, ein dialektspezifisches Element wie die PostgreSQL „on conflict do update“-Konstruktion angetroffen wurde und dann kein Dialekt für die Stringifizierung mit dem entsprechenden Zustand zum Rendern der Konstruktion bereitgestellt werden konnte, was zu internen Fehlern führte.

  Referenzen: #10753

• [sql] [bug]

  Fehler behoben, bei dem die Stringifizierung oder Kompilierung eines CTE, der sich gegen eine DML-Konstruktion wie eine insert()-Konstruktion richtete, fehlschlug, da eine Fehlklassifizierung stattfand, dass die gesamte Anweisung eine INSERT-Anweisung ist, was zu internen Fehlern führte.

schema

• [schema] [bug]

  Behoben, dass die Fehlerberichterstattung für unerwartete Schemaelemente beim Erstellen von Objekten wie Table ein Argument, das selbst als Tupel übergeben wurde, falsch behandelte, was zu einem Formatierungsfehler führte. Die Fehlermeldung wurde durch die Verwendung von f-Strings modernisiert.

  Referenzen: #10654

typing

• [typing] [bug]

  PEP-484-Typisierung für das Modul sqlalchemy.sql.functions abgeschlossen. select()-Konstrukte, die auf func-Elementen basieren, sollten nun ausgefüllte Rückgabetypen haben.

  Referenzen: #6810

asyncio

• [asyncio] [change]

  Das Dialektargument async_fallback ist nun veraltet und wird in SQLAlchemy 2.1 entfernt. Dieses Flag wurde seit einiger Zeit nicht mehr für die Testsuite von SQLAlchemy verwendet. Asyncio-Dialekte können immer noch synchron ausgeführt werden, indem Code innerhalb eines Greenlets mit greenlet_spawn() ausgeführt wird.

postgresql

• [postgresql] [bug]

  Der asyncpg-Dialekt wurde angepasst, so dass beim Aufruf der Methode terminate() zum Verwerfen einer ungültigen Verbindung der Dialekt zuerst versucht, die Verbindung ordnungsgemäß mit .close() und einem Timeout zu schließen, wenn die Operation nur innerhalb eines Async-Event-Loop-Kontextes durchgeführt wird. Dies ermöglicht es dem asyncpg-Treiber, die Beendigung eines TimeoutError zu verarbeiten, einschließlich der Möglichkeit, eine langlaufende Abfrage serverseitig zu schließen, die sonst nach Beendigung des Programms weiterlaufen könnte.

  Referenzen: #10717

mysql

• [mysql] [bug]

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

  Diese Änderung ist auch zurückportiert zu: 1.4.51

  Referenzen: #10650

tests

• [tests] [bug]

  Verbesserungen an der Testsuite, um ihre Fähigkeit, ohne installierte Python greenlet zu laufen, weiter zu stärken. Es gibt nun ein Tox-Ziel, das das Token „nogreenlet“ enthält und die Suite ohne Greenlet ausführt (beachten Sie jedoch, dass Greenlet als Teil der Tox-Konfiguration temporär installiert wird).

  Referenzen: #10747

2.0.23

Veröffentlicht: 2. November 2023

orm

• [orm] [usecase]

  Implementierung des Parameters Session.bulk_insert_mappings.render_nulls für neue Bulk-ORM-Inserts, wodurch render_nulls=True als Ausführungsoption zulässig ist. Dies ermöglicht Bulk-ORM-Inserts mit einer Mischung aus None-Werten in den Parameterwörterbüchern, um eine einzige Zeilengruppe für eine gegebene Menge von Wörterbuchschlüsseln zu verwenden, anstatt in Gruppen aufzuteilen, die die NULL-Spalten aus jedem INSERT weglassen.

  Siehe auch

  NULL-Werte in ORM Bulk INSERT-Anweisungen senden

  Referenzen: #10575

• [orm] [bug]

  Behoben, dass die Direktive __allow_unmapped__ das Zulassen von Legacy Column- / deferred()-Mappings, die dennoch Annotationen wie Any oder einen spezifischen Typ ohne Mapped[] als Typ hatten, nicht zuließ, ohne Fehler im Zusammenhang mit der Suche nach dem Attributnamen.

  Referenzen: #10516

• [orm] [bug]

  Caching-Fehler behoben, bei dem die Verwendung des with_expression()-Konstrukts in Verbindung mit den Loader-Optionen selectinload(), lazyload() gebundene Parameterwerte bei nachfolgenden Caching-Läufen nicht korrekt substituierte.

  Referenzen: #10570

• [orm] [bug]

  Fehler im ORM Annotated Declarative behoben, bei dem die Verwendung einer ClassVar, die sich dennoch auf irgendeine Weise auf eine ORM-gemappte Klassenbezeichnung bezog, nicht als ClassVar, die nicht gemappt ist, interpretiert wurde.

  Referenzen: #10472

sql

• [sql] [usecase]

  Implementierung der „Literalwertverarbeitung“ für den Interval-Datentyp für die PostgreSQL- und Oracle-Dialekte, die eine literale Darstellung von Intervallwerten ermöglicht. Pull-Request von Indivar Mishra.

  Referenzen: #9737

• [sql] [bug]

  Behoben, dass die Verwendung desselben gebundenen Parameters mehr als einmal mit literal_execute=True in einigen Kombinationen mit anderen Literal-Rendering-Parametern dazu führte, dass die falschen Werte aufgrund eines Iterationsproblems gerendert wurden.

  Diese Änderung ist auch zurückportiert zu: 1.4.50

  Referenzen: #10142

• [sql] [bug]

  NULL/NULL-Handhabung auf Compiler-Ebene für die „Literal-Prozessoren“ aller Datentypen, die eine Literal-Verarbeitung beinhalten, d. h. wenn ein Wert inline in einer SQL-Anweisung anstelle eines gebundenen Parameters gerendert wird, hinzugefügt für all jene Typen, die keine explizite „Nullwert“-Handhabung aufweisen. Zuvor war dieses Verhalten undefiniert und inkonsistent.

  Referenzen: #10535

• [sql]

  Entferntes, ungenutztes Platzhalterverfahren TypeEngine.compare_against_backend(). Diese Methode wurde von sehr alten Versionen von Alembic verwendet. Siehe https://github.com/sqlalchemy/alembic/issues/1293 für Details.

asyncio

• [asyncio] [bug]

  Fehler bei der Methode AsyncSession.close_all() behoben, die nicht korrekt funktionierte. Außerdem wurde die Funktion close_all_sessions() hinzugefügt, die dem Äquivalent von close_all_sessions() entspricht. Pull-Request von Bryan不可思议.

  Referenzen: #10421

postgresql

• [postgresql] [bug]

  2.0-Regression behoben, die durch #7744 verursacht wurde, bei der Ausdrucksketten, die PostgreSQL JSON-Operatoren mit anderen Operatoren wie Zeichenkettenkonkatenation kombinierten, die korrekte Klammerung verloren, aufgrund eines Implementierungsdetails, das spezifisch für den PostgreSQL-Dialekt ist.

  Referenzen: #10479

• [postgresql] [bug]

  SQL-Handhabung für „insertmanyvalues“ bei Verwendung des BIT-Datentyps mit dem asyncpg-Backend behoben. Das BIT unter asyncpg erfordert offenbar die Verwendung eines asyncpg-spezifischen BitString-Typs, der derzeit bei Verwendung dieses DBAPI verfügbar ist, was ihn inkompatibel mit anderen PostgreSQL-DBAPIs macht, die alle mit einfachen Bitstrings arbeiten. Eine zukünftige Korrektur in Version 2.1 wird diesen Datentyp für alle PG-Backends normalisieren. Pull-Request von Sören Oldag.

  Referenzen: #10532

mysql

• [mysql] [bug]

  Eine neue Inkompatibilität in der MySQL „pre-ping“-Routine wurde repariert, bei der das an connection.ping() übergebene False-Argument, das eine unerwünschte „automatische Wiederverbindung“-Funktion deaktivieren soll, in MySQL-Treibern und Backends als veraltet markiert ist und bei einigen Versionen von MySQLs nativen Client-Treibern Warnungen erzeugt. Es wurde für mysqlclient entfernt, während es für PyMySQL und auf PyMySQL basierende Treiber irgendwann veraltet sein wird, so dass eine API-Introspektion verwendet wird, um gegen diese verschiedenen Entfernungsstufen zukunftssicher zu sein.

  Diese Änderung ist auch zurückportiert zu: 1.4.50

  Referenzen: #10492

mariadb

• [mariadb] [bug]

  Angepasste die MySQL/MariaDB-Dialekte, um eine generierte Spalte unter MariaDB standardmäßig auf NULL zu setzen, wenn Column.nullable nicht mit einem expliziten True oder False Wert angegeben wurde, da MariaDB die Phrase „NOT NULL“ mit einer generierten Spalte nicht unterstützt. Pull-Request von Indivar.

  Referenzen: #10056

• [mariadb] [bug] [regression]

  Es wurde ein Workaround für ein scheinbar intrinsisches Problem bei MySQL/MariaDB-Treibern etabliert, bei dem ein RETURNING-Ergebnis für DELETE DML, das keine Zeilen mit den „leeren IN“-Kriterien von SQLAlchemy zurückgibt, keinen Cursor bereitstellt. Dies führt zu einem Ergebnis, das keine Zeilen zurückgibt, was zu Regressionen für das ORM führt, das in der 2.0-Serie RETURNING für Massen-DELETE-Anweisungen für die Funktion „synchronize session“ verwendet. Zur Behebung wird, wenn der spezifische Fall „keine Beschreibung bei gegebenem RETURNING“ erkannt wird, ein „leeres Ergebnis“ mit einer korrekten Cursor-Beschreibung generiert und anstelle des nicht funktionierenden Cursors verwendet.

  Referenzen: #10505

mssql

• [mssql] [usecase]

  Unterstützung für den aioodbc-Treiber für SQL Server hinzugefügt, der auf pyodbc und der allgemeinen aio*-Dialektarchitektur aufbaut.

  Siehe auch

  aioodbc - in der Dokumentation des SQL Server-Dialekts.

  Referenzen: #6521

• [mssql] [bug] [reflection]

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

  Diese Änderung ist auch zurückportiert zu: 1.4.50

  Referenzen: #10504

oracle

• [oracle] [bug]

  Problem im Interval-Datentyp behoben, bei dem die Oracle-Implementierung nicht für die DDL-Generierung verwendet wurde, was dazu führte, dass die Parameter day_precision und second_precision ignoriert wurden, obwohl sie von diesem Dialekt unterstützt werden. Pull-Request von Indivar.

  Referenzen: #10509

• [oracle] [bug]

  Problem behoben, bei dem der cx_Oracle-Dialekt eine niedrigere cx_Oracle-Version (7.x) beanspruchte als tatsächlich in der 2.0-Serie von SQLAlchemy unterstützt wurde. Der Dialekt importiert Symbole, die nur in cx_Oracle 8 oder höher vorhanden sind. Daher wurden Laufzeit-Dialektprüfungen sowie die setup.cfg-Anforderungen aktualisiert, um diese Kompatibilität widerzuspiegeln.

  Referenzen: #10470

2.0.22

Veröffentlicht: 12. Oktober 2023

orm

• [orm] [usecase]

  Methode Session.get_one() hinzugefügt, die sich wie Session.get() verhält, aber eine Ausnahme auslöst, anstatt None zurückzugeben, wenn keine Instanz mit dem angegebenen Primärschlüssel gefunden wurde. Pull-Request von Carlos Sousa.

  Referenzen: #10202

• [orm] [usecase]

  Option zum permanenten Schließen von Sessions hinzugefügt. Wenn der neue Parameter Session.close_resets_only auf False gesetzt ist, wird verhindert, dass eine Session nach dem Aufruf von Session.close() weitere Operationen durchführt.

  Neue Methode Session.reset() hinzugefügt, die eine Session in ihren Anfangszustand zurückversetzt. Dies ist ein Alias für Session.close(), es sei denn, Session.close_resets_only ist auf False gesetzt.

  Referenzen: #7787

• [orm] [bug]

  Eine breite Palette von mapped_column()-Parametern, die nicht übertragen wurden, wenn das Objekt mapped_column() innerhalb eines pep-593 Annotated-Objekts verwendet wurde, wurde behoben. Dazu gehören mapped_column.sort_order, mapped_column.deferred, mapped_column.autoincrement, mapped_column.system, mapped_column.info usw.

  Zusätzlich bleibt es nicht unterstützt, Dataclass-Argumente wie mapped_column.kw_only, mapped_column.default_factory usw. innerhalb des mapped_column(), das von Annotated empfangen wird, anzugeben, da dies mit pep-681 Dataclass Transforms nicht unterstützt wird. Eine Warnung wird nun ausgegeben, wenn diese Parameter auf diese Weise innerhalb von Annotated verwendet werden (und sie werden weiterhin ignoriert).

  Referenzen: #10046, #10369

• [orm] [bug]

  Problem behoben, bei dem das Aufrufen von Result.unique() mit einer neuen SELECT-Abfrage im ORM, bei der eine oder mehrere Spalten Werte von „unbekannter Hashbarkeit“ ergeben, typischerweise bei Verwendung von JSON-Funktionen wie func.json_build_object() ohne Typangabe, intern fehlschlagen würde, wenn die zurückgegebenen Werte tatsächlich nicht hashbar wären. Das Verhalten wurde repariert, um die Objekte in diesem Fall auf Hashbarkeit zu testen und eine informative Fehlermeldung auszugeben, falls nicht. Beachten Sie, dass für Werte von „bekannter Unhashbarkeit“, wie z. B. bei direkter Verwendung der Typen JSON oder ARRAY, bereits eine informative Fehlermeldung ausgegeben wurde.

  Die „Hashbarkeitsprüfung“-Korrektur hier wird auch auf die Legacy-Klasse Query angewendet. Im Legacy-Fall wird Result.unique() jedoch für fast alle Abfragen verwendet, daher wird hier keine neue Warnung ausgegeben; das Legacy-Verhalten, in diesem Fall auf die Verwendung von id() zurückzugreifen, wird beibehalten, mit der Verbesserung, dass ein unbekannter Typ, der sich als hashbar erweist, nun eindeutig gemacht wird, während dies früher nicht der Fall war.

  Referenzen: #10459

• [orm] [bug]

  Regression in der kürzlich überarbeiteten „insertmanyvalues“-Funktion (wahrscheinlich Problem #9618) behoben, bei der das ORM versehentlich versuchte, ein Nicht-RETURNING-Ergebnis als RETURNING zu interpretieren. Dies geschah im Fall, in dem der Parameter implicit_returning=False auf die gemappte Table angewendet wurde, was darauf hinweist, dass „insertmanyvalues“ nicht verwendet werden kann, wenn die Primärschlüsselwerte nicht angegeben sind.

  Referenzen: #10453

• [orm] [bug]

  Bug behoben, bei dem with_loader_criteria() im ORM nicht auf ein Select.join() angewendet wurde, bei dem die ON-Klausel als Plain-SQL-Vergleich angegeben wurde, anstatt als Beziehungsziel oder Ähnliches.

  Update - dies behob auch ein Problem, bei dem Einzelvererbungs-Kriterien nicht korrekt auf eine Unterklassen-Entität angewendet wurden, die nur in der select_from()-Liste erschien, siehe #11412

  Referenzen: #10365, #11412

• [orm] [bug]

  Problem behoben, bei dem Mapped-Symbole wie WriteOnlyMapped und DynamicMapped nicht korrekt aufgelöst werden konnten, wenn sie als Element eines Untermoduls in der angegebenen Annotation referenziert wurden, unter Annahme von Zeichenketten-basierten oder „Future Annotations“-Stil-Annotationen.

  Referenzen: #10412

• [orm] [bug]

  Problem mit der Deklarationsoption __allow_unmapped__ behoben, bei der Typen, die mit Kollektionstypen wie list[SomeClass] im Gegensatz zum Typing-Konstrukt List[SomeClass] deklariert wurden, nicht korrekt erkannt wurden. Pull-Request von Pascal Corpet.

  Referenzen: #10385

engine

• [engine] [bug]

  Problem in einigen Dialekten behoben, bei denen der Dialekt fälschlicherweise ein leeres Ergebnis für eine INSERT-Anweisung zurückgeben konnte, die tatsächlich keine Zeilen zurückgibt, aufgrund von Artefakten aus dem Pre- oder Post-Fetching des Primärschlüssels der Zeile oder noch vorhandener Zeilen. Betroffene Dialekte waren asyncpg, alle mssql-Dialekte.

• [engine] [bug]

  Problem behoben, bei dem unter bestimmten Garbage-Collection-/Ausnahmeszenarien die Bereinigungsroutine des Connection-Pools aufgrund eines unerwarteten Zustands einen Fehler auslöste, der unter bestimmten Bedingungen reproduzierbar ist.

  Referenzen: #10414

sql

• [sql] [bug]

  Problem behoben, bei dem die Referenzierung eines FROM-Eintrags in der SET-Klausel einer UPDATE-Anweisung diesen nicht in die FROM-Klausel der UPDATE-Anweisung aufnahm, wenn dieser Eintrag nirgendwo sonst in der Anweisung vorkam; dies tritt derzeit für CTEs auf, die mit Update.add_cte() hinzugefügt wurden, um die gewünschte CTE am Anfang der Anweisung bereitzustellen.

  Referenzen: #10408

• [sql] [bug]

  Die 2.0-Regression, bei der die DDL-Konstruktion nicht mehr __repr__() wurde, da das entfernte on-Attribut nicht berücksichtigt wurde, wurde behoben. Pull-Request von Iuri de Silvio.

  Referenzen: #10443

typing

• [typing] [bug]

  Tippfehlerproblem behoben, bei dem die an Values übergebene Argumentliste zu restriktiv an List statt an Sequence gebunden war. Pull-Request von Iuri de Silvio.

  Referenzen: #10451

• [typing] [bug]

  Aktualisierungen am Code, um Mypy 1.6.0 zu unterstützen.

asyncio

• [asyncio] [bug]

  Der Parameter AsyncSession.get.execution_options wurde korrigiert, der nicht an die zugrunde liegende Session weitergegeben und stattdessen ignoriert wurde.

mariadb

• [mariadb] [bug]

  Der mariadb-connector-Treiber wurde modifiziert, um den Wert von cursor.rowcount für alle Abfragen vorzuladen, um Tools wie Pandas entgegenzukommen, die Result.rowcount auf diese Weise hartkodiert aufrufen. SQLAlchemy lädt normalerweise cursor.rowcount nur für UPDATE/DELETE-Anweisungen vor und leitet ansonsten an den DBAPI weiter, wo er -1 zurückgeben kann, wenn kein Wert verfügbar ist. Der mariadb-connector unterstützt jedoch nicht den Aufruf von cursor.rowcount, nachdem der Cursor selbst geschlossen wurde, und löst stattdessen einen Fehler aus. Generische Testunterstützung wurde hinzugefügt, um sicherzustellen, dass alle Backends das Zulassen von Result.rowcount (d. h. Rückgabe eines Integer-Werts mit -1 für „nicht verfügbar“) nach dem Schließen des Ergebnisses unterstützen.

  Referenzen: #10396

• [mariadb] [bug]

  Weitere Korrekturen für den mariadb-connector-Dialekt zur Unterstützung von UUID-Datumsangaben in den Ergebnissen von INSERT..RETURNING-Anweisungen.

mssql

• [mssql] [bug]

  Bug behoben, bei dem die Regel, die die Ausgabe von ORDER BY innerhalb von Unterabfragen auf SQL Server verhindert, nicht deaktiviert wurde, wenn die Methode select.fetch() verwendet wurde, um Zeilen in Verbindung mit WITH TIES oder PERCENT zu begrenzen. Dies verhinderte die Verwendung gültiger Unterabfragen mit TOP/ORDER BY.

  Referenzen: #10458

2.0.21

Veröffentlicht: 18. September 2023

orm

• [orm] [bug]

  Die Interpretation des „Ziel“-Entitäts durch das ORM, die innerhalb von Update und Delete verwendet wird, wurde angepasst, um das Ziel „from“-Objekt, das an die Anweisung übergeben wird, nicht zu beeinträchtigen, wie z. B. bei der Übergabe eines ORM-gemappten aliased-Konstrukts, das in einer Phrase wie „UPDATE FROM“ beibehalten werden sollte. Fälle wie die ORM-Session-Synchronisierung unter Verwendung von „SELECT“-Anweisungen, wie bei MySQL/MariaDB, haben weiterhin Probleme mit UPDATE/DELETE dieser Form, daher ist es am besten, synchonize_session zu deaktivieren, wenn DML-Anweisungen dieser Art verwendet werden.

  Referenzen: #10279

• [orm] [bug]

  Neue Funktionalität für die Loader-Option selectin_polymorphic() hinzugefügt, die es ermöglicht, andere Loader-Optionen als Geschwister zu bündeln und sich auf eine ihrer Unterklassen innerhalb der Unteroptionen einer übergeordneten Loader-Option zu beziehen. Zuvor wurde dieses Muster nur unterstützt, wenn selectin_polymorphic() auf der obersten Ebene der Optionen für die Abfrage stand. Siehe neuer Dokumentationsabschnitt für ein Beispiel.

  Als Teil dieser Änderung wurde das Verhalten der Methode Load.selectin_polymorphic() / Loader-Strategie verbessert, sodass die Unterklassenladung nicht die meisten bereits geladenen Spalten aus der Elterntabelle lädt, wenn die Option auf eine Klasse angewendet wird, die bereits beziehungsweise geladen wird. Zuvor funktionierte die Logik zum Laden nur der Unterklassenspalten nur für eine Klassenladung auf oberster Ebene.

  Siehe auch

  Anwenden von Loader-Optionen, wenn selectin_polymorphic selbst eine Unteroption ist

  Referenzen: #10348

engine

• [engine] [bug]

  Eine Reihe von Reflexionsproblemen, die die PostgreSQL-, MySQL/MariaDB- und SQLite-Dialekte betrafen, wurden behoben, als Fremdschlüsselbeschränkungen reflektiert wurden, wobei die Zielspalte Klammern im Tabellen- oder Spaltennamen enthielt.

  Referenzen: #10275

sql

• [sql] [usecase]

  Der Enum-Datentyp wurde angepasst, um ein Argument von None für den Parameter Enum.length zu akzeptieren, was zu einem VARCHAR oder einem anderen Texttyp ohne Länge in der resultierenden DDL führt. Dies ermöglicht, dass neue Elemente beliebiger Länge zum Typ hinzugefügt werden können, nachdem er im Schema vorhanden ist. Pull-Request von Eugene Toder.

  Referenzen: #10269

• [sql] [usecase]

  Neue generische SQL-Funktion aggregate_strings hinzugefügt, die einen SQL-Ausdruck und ein Trennzeichen akzeptiert und Zeichenketten über mehrere Zeilen zu einem einzigen aggregierten Wert verkettet. Die Funktion wird pro Backend in Funktionen wie group_concat(), string_agg() oder LISTAGG() kompiliert. Pull-Request von Joshua Morris.

  Referenzen: #9873

• [sql] [bug]

  Die Operatorrangfolge für den Zeichenketten-Verkettungsoperator wurde so angepasst, dass sie gleich der von Zeichenketten-Abgleichsoperatoren ist, wie z. B. ColumnElement.like(), ColumnElement.regexp_match(), ColumnElement.match() usw., sowie einfache ==, die dieselbe Rangfolge wie Zeichenketten-Vergleichsoperatoren hat. Dadurch werden Klammern auf einen Zeichenketten-Verkettungsausdruck angewendet, der einem Zeichenketten-Abgleichsoperator folgt. Dies dient Backends wie PostgreSQL, bei denen der Operator „regexp match“ anscheinend eine höhere Rangfolge hat als der Zeichenketten-Verkettungsoperator.

  Referenzen: #9610

• [sql] [bug]

  Die Verwendung von hashlib.md5() im DDL-Compiler, die zur Erzeugung deterministischer vierstelliger Suffixe für lange Index- und Bezeichnungsnamen in DDL-Anweisungen verwendet wird, wurde qualifiziert, um den Python 3.9+-Parameter usedforsecurity=False einzuschließen, damit Python-Interpreter, die für eingeschränkte Umgebungen wie FIPS erstellt wurden, diesen Aufruf nicht als sicherheitsrelevant betrachten.

  Referenzen: #10342

• [sql] [bug]

  Die Values-Konstruktion erstellt nun automatisch einen Proxy (d. h. eine Kopie) einer column, wenn die Spalte bereits mit einer vorhandenen FROM-Klausel verbunden war. Dies ermöglicht, dass ein Ausdruck wie values_obj.c.colname die korrekte FROM-Klausel ergibt, auch wenn colname als column übergeben wurde, die bereits mit einer früheren Values oder einer anderen Tabellenkonstruktion verwendet wurde. Ursprünglich galt dies als Kandidat für einen Fehlerzustand, aber dieses Muster ist wahrscheinlich bereits weit verbreitet, daher wird es nun zur Unterstützung hinzugefügt.

  Referenzen: #10280

schema

• [schema] [bug]

  Die Darstellung des nur für Oracle geltenden Parameters Identity.order, der sowohl zu Sequence als auch zu Identity gehört, wurde so modifiziert, dass er nur für den Oracle-Backend stattfindet und nicht für andere Backends wie PostgreSQL. Eine zukünftige Version wird die Parameter Identity.order, Sequence.order und Identity.on_null in Oracle-spezifische Namen umbenennen und die alten Namen veralten lassen. Diese Parameter gelten nur für Oracle.

  Diese Änderung ist auch zurückportiert zu: 1.4.50

  Referenzen: #10207

typing

• [typing] [usecase]

  Der enthaltene Typ für Mapped wurde kovariant gemacht; dies dient einer größeren Flexibilität für Endbenutzer-Typisierungsszenarien, wie z. B. die Verwendung von Protokollen zur Darstellung bestimmter gemappter Klassenstrukturen, die an andere Funktionen übergeben werden. Als Teil dieser Änderung wurde der enthaltene Typ auch für abhängige und verwandte Typen wie SQLORMOperations, WriteOnlyMapped und SQLColumnExpression kovariant gemacht. Pull-Request von Roméo Després.

  Referenzen: #10288

• [typing] [bug]

  Regression, die in 2.0.20 durch die Behebung von #9600 eingeführt wurde, wurde behoben, die versuchte, eine formalere Typisierung zu MetaData.naming_convention hinzuzufügen. Diese Änderung verhinderte, dass einfache Benennungskonventionswörterbücher die Typisierung bestanden, und wurde angepasst, damit einfache Wörterbücher aus Zeichenketten für Schlüssel sowie Wörterbücher, die Beschränkungstypen als Schlüssel verwenden, oder eine Mischung aus beidem, wieder akzeptiert werden.

  Als Teil dieser Änderung werden auch weniger gebräuchliche Formen des Benennungskonventionswörterbuchs typisiert, einschließlich der Tatsache, dass es derzeit Constraint-Typobjekte als Schlüssel zulässt.

  Referenzen: #10264, #9284

• [typing] [bug]

  Behobene Typannotation für __class_getitem__(), angewendet auf die Visitable-Klasse am Ende von Expression-Konstrukten, um Any für einen Schlüssel anstelle von str zu akzeptieren. Dies hilft bei einigen IDEs wie PyCharm beim Versuch, Typannotationen für SQL-Konstrukte mit generischen Selektoren zu schreiben. Pull-Request von Jordan Macdonald.

  Referenzen: #9878

• [typing] [bug]

  Die Kernklasse „SQL-Element“ SQLCoreOperations wurde repariert, um die __hash__()-Methode aus einer Typisierungs-Perspektive zu unterstützen, da Objekte wie Column und ORM InstrumentedAttribute hashbar sind und als Schlüssel in Wörterbüchern in der öffentlichen API für die Update- und Insert-Konstrukte verwendet werden. Zuvor wussten Typchecker nicht, dass das Wurzel-SQL-Element hashbar war.

  Referenzen: #10353

• [typing] [bug]

  Typisierungsproblem mit Existing.select_from() behoben, das die Verwendung mit ORM-Klassen verhinderte.

  Referenzen: #10337

• [typing] [bug]

  Aktualisierte Typannotationen für ORM-Ladeoptionen, die auf die Akzeptanz von nur „*“ anstelle von beliebigen Zeichenketten für Zeichenkettenargumente beschränkt sind. Pull-Request von Janek Nouvertné.

  Referenzen: #10131

postgresql

• [postgresql] [bug]

  Behobene Regression, die in Version 2.0 aufgrund von #8491 auftrat, bei der der überarbeitete „Ping“ für PostgreSQL-Dialekte, wenn der Parameter create_engine.pool_pre_ping verwendet wurde, die Verwendung von asyncpg mit PGBouncer im „Transaktions“-Modus beeinträchtigte, da die mehreren PostgreSQL-Befehle, die von asyncpg ausgegeben wurden, über mehrere Verbindungen verteilt werden konnten, was zu Fehlern führte. Dies lag an der fehlenden Transaktion um diesen neu überarbeiteten „Ping“. Der Ping wird jetzt innerhalb einer Transaktion aufgerufen, genauso wie es bei allen anderen Backends implizit ist, die auf der pep-249 DBAPI basieren. Dies garantiert, dass die von asyncpg für diesen Befehl gesendete Befehlsreihe auf derselben Backend-Verbindung aufgerufen wird, ohne dass sie mitten im Befehl zu einer anderen Verbindung springt. Die Transaktion wird nicht verwendet, wenn der asyncpg-Dialekt im „AUTOCOMMIT“-Modus verwendet wird, der mit dem PGBouncer-Transaktionsmodus weiterhin inkompatibel ist.

  Referenzen: #10226

misc

• [bug] [setup]

  Behobenes sehr altes Problem, bei dem die vollständige Ausdehnung von SQLAlchemy-Modulen, einschließlich sqlalchemy.testing.fixtures, außerhalb eines Pytest-Laufs nicht importiert werden konnte. Dies eignet sich für Inspektionswerkzeuge wie pkgutil, die versuchen, alle installierten Module in allen Paketen zu importieren.

  Referenzen: #10321

2.0.20

Veröffentlicht: 15. August 2023

orm

• [orm] [usecase]

  Implementierung des „RETURNING ‚*‘“-Anwendungsfalls für ORM-aktivierte DML-Anweisungen. Dies wird in so vielen Fällen wie möglich gerendert und gibt die ungefilterte Ergebnismenge zurück, wird jedoch nicht für mehr-Parameter „ORM Bulk INSERT“-Anweisungen unterstützt, die spezifische Rendering-Anforderungen für Spalten haben.

  Referenzen: #10192

• [orm] [bug]

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

  Diese Änderung ist auch zurückportiert zu: 1.4.50

  Referenzen: #10223

• [orm] [bug]

  Behobenes Problem, bei dem die ORM-Generierung eines SELECT aus einem verknüpften Vererbungsmodell mit gleichnamigen Spalten in Oberklasse und Unterklasse irgendwie nicht die richtige Liste von Spaltennamen an den CTE-Konstrukt sendete, als die RECURSIVE-Spaltenlisten generiert wurden.

  Referenzen: #10169

• [orm] [bug]

  Behobenes recht großes Problem, bei dem Ausführungsoptionen, die an Session.execute() übergeben wurden, sowie Ausführungsoptionen, die lokal für die ORM-ausgeführte Anweisung selbst waren, nicht an Eager-Loader wie selectinload(), immediateload() und sqlalchemy.orm.subqueryload() weitergegeben wurden. Dies machte es unmöglich, Dinge wie das Deaktivieren des Caches für eine einzelne Anweisung oder die Verwendung von schema_translate_map für eine einzelne Anweisung, sowie die Verwendung benutzerdefinierter Ausführungsoptionen. Eine Änderung wurde vorgenommen, bei der **alle** benutzerseitigen Ausführungsoptionen für Session.execute() an zusätzliche Lader weitergegeben werden.

  Als Teil dieser Änderung kann die Warnung vor „übertrieben tiefen“ Eager-Ladern, die zur Deaktivierung des Cachings führt, pro Anweisung unterdrückt werden, indem execution_options={"compiled_cache": None} an Session.execute() übergeben wird, was das Caching für die gesamte Reihe von Anweisungen in diesem Geltungsbereich deaktiviert.

  Referenzen: #10231

• [orm] [bug]

  Behobenes Problem, bei dem das interne Klonen, das vom ORM für Ausdrücke wie Comparator.any() zur Erzeugung korrelierter EXISTS-Konstrukte verwendet wird, die Funktion zur Warnung vor „kartesischen Produkten“ des SQL-Kompilierers beeinträchtigte. Dies führte dazu, dass der SQL-Kompilierer warnte, obwohl alle Elemente der Anweisung korrekt verknüpft waren.

  Referenzen: #10124

• [orm] [bug]

  Behobenes Problem, bei dem die Ladefunktion lazy="immediateload" unter Umständen, unter denen der Ladevorgang nicht stattfinden sollte (z. B. bei rekursiven, selbstreferenziellen Ladevorgängen), ein internes Lade-Token in das ORM-abgebildete Attribut einfügte. Als Teil dieser Änderung berücksichtigt die Ladefunktion lazy="immediateload" jetzt den Parameter relationship.join_depth für selbstreferenzielle Eager-Ladevorgänge auf dieselbe Weise wie bei anderen Eager-Ladern. Wenn er nicht gesetzt oder auf Null gesetzt ist, findet kein selbstreferenzieller Immediateload statt; ein Wert von eins oder höher führt zum Immediateload bis zu dieser Tiefe.

  Referenzen: #10139

• [orm] [bug]

  Behobenes Problem, bei dem Wörterbuch-basierte Sammlungen wie attribute_keyed_dict() nicht vollständig gepickelt/entpickelt wurden, was zu Problemen beim Versuch führte, eine solche Sammlung nach dem Entpickeln zu verändern.

  Referenzen: #10175

• [orm] [bug]

  Behobenes Problem, bei dem das Verketten von load_only() oder die Wildcard-Verwendung von defer() aus einem anderen Eager-Lader mittels eines aliased() gegen eine verknüpfte Vererbungsunterklasse dazu führte, dass die Spalten, die lokal zur Oberklasse gehörten, nicht wirksam wurden.

  Referenzen: #10125

• [orm] [bug]

  Behobenes Problem, bei dem ein ORM-aktivierter select()-Konstrukt keine CTEs rendert, die nur über die Methode Select.add_cte() hinzugefügt wurden und die sonst nicht in der Anweisung referenziert wurden.

  Referenzen: #10167

examples

• [examples] [bug]

  Die dogpile_caching-Beispiele wurden für 2.0-Style-Abfragen aktualisiert. Innerhalb der „Caching Query“-Logik selbst wurde eine Bedingung hinzugefügt, um zwischen Query und select() bei der Invalidierung zu unterscheiden.

engine

• [engine] [bug]

  Behobenes kritisches Problem, bei dem das Setzen von create_engine.isolation_level auf AUTOCOMMIT (im Gegensatz zur Verwendung der Methode Engine.execution_options()) dazu führte, dass „autocommit“ für eine gepoolte Verbindung nicht wiederhergestellt wurde, wenn eine alternative Isolationsstufe temporär mit Connection.execution_options.isolation_level ausgewählt wurde.

  Referenzen: #10147

sql

• [sql] [bug]

  Behobenes Problem, bei dem das Entpickeln einer Column oder eines anderen ColumnElement das korrekte „Comparator“-Objekt, das zur Generierung von SQL-Ausdrücken verwendet wird, die spezifisch für das Typobjekt sind, nicht wiederherstellte.

  Diese Änderung ist auch zurückportiert zu: 1.4.50

  Referenzen: #10213

typing

• [typing] [usecase]

  Hinzugefügte neue, nur für die Typisierung bestimmte Hilfsfunktionen Nullable() und NotNullable(), um eine Spalte oder ORM-Klasse als nullable bzw. nicht nullable zu typisieren. Diese Funktionen sind zur Laufzeit No-Ops und geben die Eingabe unverändert zurück.

  Referenzen: #10173

• [typing] [bug]

  Typisierungsverbesserungen

  • CursorResult wird für einige Formen von Session.execute() zurückgegeben, wenn DML ohne RETURNING verwendet wird

  • Korrigierter Typ für den Parameter Query.with_for_update.of innerhalb von Query.with_for_update()

  • Verbesserungen an _DMLColumnArgument, einem Typ, der von einigen DML-Methoden zum Übergeben von Spaltenausdrücken verwendet wird

  • Überladung zu literal() hinzugefügt, damit der Rückgabetyp als BindParameter[NullType] abgeleitet wird, wenn der literal.type_-Parameter None ist

  • Überladungen zu ColumnElement.op() hinzugefügt, damit der abgeleitete Typ, wenn ColumnElement.op.return_type nicht angegeben ist, Callable[[Any], BinaryExpression[Any]] ist

  • Fehlende Überladung zu ColumnElement.__add__() hinzugefügt

  Pull-Request von Mehdi Gmira.

  Referenzen: #9185

• [typing] [bug]

  Behobenes Problem in den Methoden von Session und AsyncSession wie Session.connection(), bei denen der Parameter Session.connection.execution_options auf einen internen, nicht benutzerseitigen Typ hartkodiert war.

  Referenzen: #10182

asyncio

• [asyncio] [usecase]

  Hinzugefügte neue Methoden AsyncConnection.aclose() als Synonym für AsyncConnection.close() und AsyncSession.aclose() als Synonym für AsyncSession.close() zu den Objekten AsyncConnection und AsyncSession, um die Kompatibilität mit dem Konstrukt @contextlib.aclosing der Python-Standardbibliothek zu gewährleisten. Pull-Request von Grigoriev Semyon.

  Referenzen: #9698

mysql

• [mysql] [usecase]

  Aktualisierter aiomysql-Dialekt, da der Dialekt anscheinend wieder gepflegt wird. Wieder in die CI-Tests aufgenommen mit Version 0.2.0.

  Diese Änderung ist auch zurückportiert zu: 1.4.50

2.0.19

Veröffentlicht: 15. Juli 2023

orm

• [orm] [bug]

  Behobenes Problem, bei dem das direkte Setzen einer Beziehungsammlung, bei der ein Objekt aus der neuen Sammlung bereits vorhanden war, kein Kaskadenereignis für dieses Objekt auslöste, was dazu führte, dass es nicht zur Session hinzugefügt wurde, wenn es noch nicht vorhanden war. Dies ähnelt in der Natur #6471 und ist aufgrund der Entfernung von cascade_backrefs in der 2.0-Serie ein offensichtlicheres Problem. Das Ereignis AttributeEvents.append_wo_mutation(), das im Rahmen von #6471 hinzugefügt wurde, wird nun auch für vorhandene Mitglieder einer Sammlung emittiert, die in einer Bulk-Menge derselben Sammlung vorhanden sind.

  Referenzen: #10089

• [orm] [bug]

  Behobenes Problem, bei dem Objekte, die über Backref mit einer nicht geladenen Sammlung assoziiert waren, aber nicht in die Session gemerged wurden, aufgrund der Entfernung von cascade_backrefs in der 2.0-Serie, keine Warnung ausgaben, dass diese Objekte nicht in einen Flush einbezogen wurden, obwohl sie ausstehende Mitglieder der Sammlung waren. In anderen solchen Fällen wird eine Warnung ausgegeben, wenn eine zu flushende Sammlung nicht angehängte Objekte enthält, die im Wesentlichen verworfen werden. Die Hinzufügung der Warnung für Backref-Pending-Sammlungsmitglieder schafft mehr Konsistenz mit Sammlungen, die zu unterschiedlichen Zeiten basierend auf unterschiedlichen Relationship-Lade-Strategien vorhanden oder nicht vorhanden und möglicherweise geflusht oder nicht geflusht sind.

  Referenzen: #10090

• [orm] [bug] [regression]

  Behobene zusätzliche Regression, die durch #9805 verursacht wurde, bei der die aggressivere Weitergabe des „ORM“-Flags auf Anweisungen zu einem internen Attributfehler führen konnte, wenn eine ORM Query-Konstrukt eingebettet war, das dennoch keine ORM-Entitäten enthielt, in einer Core SQL-Anweisung, in diesem Fall ORM-aktivierte UPDATE- und DELETE-Anweisungen.

  Referenzen: #10098

engine

• [engine] [bug]

  Umbenannt Row.t und Row.tuple() in Row._t und Row._tuple(). Dies geschieht gemäß der Richtlinie, dass alle Methoden und vordefinierten Attribute von Row im Stil der namedtuple der Python-Standardbibliothek sein sollen, bei der alle festen Namen mit einem führenden Unterstrich versehen sind, um Namenskonflikte mit vorhandenen Spaltennamen zu vermeiden. Die vorherige Methode/Attribut ist nun veraltet und gibt eine Deprecation-Warnung aus.

  Referenzen: #10093

• [engine] [bug]

  Erkennung von Nicht-String-, Nicht-URL-Objekten in der Funktion make_url() hinzugefügt. Dies ermöglicht, dass ArgumentError sofort ausgelöst wird, anstatt später zu Fehlern zu führen. Spezielle Logik stellt sicher, dass Mock-Formen von URL durchgelassen werden. Pull-Request von Grigoriev Semyon.

  Referenzen: #10079

postgresql

• [postgresql] [bug]

  Behobene Regression, die durch Verbesserungen bei der PostgreSQL-URL-Analyse in #10004 verursacht wurde, bei der „host“-Query-String-Argumente mit Doppelpunkten zur Unterstützung verschiedener Drittanbieter-Proxy-Server und/oder Dialekte nicht korrekt analysiert wurden, da diese als host:port-Kombinationen interpretiert wurden. Die Analyse wurde aktualisiert, um einen Doppelpunkt nur dann als Angabe eines host:port-Wertes zu betrachten, wenn der Hostname nur alphanumerische Zeichen mit Punkten oder Bindestrichen enthält (z. B. keine Schrägstriche), gefolgt von genau einem Doppelpunkt, gefolgt von einem rein numerischen Token von null oder mehr Ziffern. In allen anderen Fällen wird die vollständige Zeichenkette als Host übernommen.

  Referenzen: #10069

• [postgresql] [bug]

  Behobenes Problem, bei dem Vergleiche mit dem Datentyp CITEXT die rechte Seite zu VARCHAR konvertierten, was dazu führte, dass die rechte Seite nicht als CITEXT-Datentyp interpretiert wurde, für die Dialekte asyncpg, psycopg3 und pg80000. Dies führte dazu, dass der CITEXT-Typ praktisch unbrauchbar war; dies ist nun behoben und die Testsuite wurde korrigiert, um ordnungsgemäß zu überprüfen, dass Ausdrücke korrekt gerendert werden.

  Referenzen: #10096

2.0.18

Veröffentlicht: 5. Juli 2023

engine

• [engine] [bug]

  Die Funktion create_engine.schema_translate_map wurde so angepasst, dass nun **alle** Schemanamen in der Anweisung tokenisiert werden, unabhängig davon, ob ein bestimmter Name in der unmittelbaren Schematransformationskarte enthalten ist oder nicht. Außerdem wird im Falle einer fehlenden Entsprechung im aktuellen Transformationskarteneintrag auf die ursprüngliche Bezeichnung zurückgegriffen, was die wiederholte Verwendung eines kompilierten Objekts mit unterschiedlichen Schematransformationskarten zur Laufzeit ermöglicht, ohne dass es zu Fehlern kommt. Zusätzlich wurde die Erkennung von schema_translate_map-Dictionaries hinzugefügt, die über Aufrufe hinweg einen None-Schlüssel hinzufügen oder verlieren. Dies wirkt sich auf die Kompilierung der Anweisung aus und ist nicht mit dem Caching vereinbar. In diesen Fällen wird eine Ausnahme ausgelöst.

  Referenzen: #10025

sql

• [sql] [bug]

  Behobenes Problem, bei dem die Methode ColumnOperators.regexp_match() bei Verwendung von „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() mit sowohl den Flags als auch dem eigentlichen Ersetzungsausdruck. Die Flags werden nun als feste Modifikator-Zeichenketten dargestellt, die als SafeStrings gerendert werden, anstatt als gebundene Parameter, und der Ersetzungsausdruck wird im primären Teil des „binären“ Elements festgelegt, damit er einen geeigneten Cache-Schlüssel erzeugt.

  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 Strings gerendert werden, während sie zuvor als vollständige SQL-Ausdrücke, typischerweise gebundene Parameter, gerendert wurden. Diese Parameter sollten immer als einfache Python-Strings und nicht als SQL-Ausdruckskonstrukte übergeben werden; es wird nicht erwartet, dass SQL-Ausdruckskonstrukte für diesen Parameter in der Praxis verwendet wurden, daher handelt es sich um eine rückwärts inkompatible Ä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 Regex-Implementierungen hatten (keine solchen Dialekte konnten bei einer Suche gefunden werden, daher wird die Auswirkung als gering eingeschätzt), müssten die Traversierung der Struktur anpassen, um dies zu berücksichtigen.

  Diese Änderung wird auch zurückportiert nach: 1.4.49

  Referenzen: #10042

• [sql] [bug]

  Behobenes Problem im meist internen Konstrukt CacheKey, bei dem der Operator __ne__() nicht korrekt implementiert war, was zu unsinnigen Ergebnissen beim Vergleich von CacheKey-Instanzen untereinander führte.

  Diese Änderung wird auch zurückportiert nach: 1.4.49

extensions

• [extensions] [usecase]

  Neue Option zu association_proxy() hinzugefügt: association_proxy.create_on_none_assignment; wenn einem Assoziationsproxy, der auf eine skalare Beziehung verweist, der Wert None zugewiesen wird und das referenzierte Objekt nicht vorhanden ist, wird ein neues Objekt über den Ersteller erstellt. Dies war anscheinend ein undefiniertes Verhalten in der Serie 1.2, das stillschweigend entfernt wurde.

  Referenzen: #10013

typing

• [typing] [usecase]

  Verbesserte Typisierung bei der Verwendung von eigenständigen Operatorfunktionen aus sqlalchemy.sql.operators wie sqlalchemy.sql.operators.eq.

  Referenzen: #10054

• [typing] [bug]

  Einige Typisierungen im Konstrukt aliased() wurden korrigiert, sodass ein mit Table.alias() aliasierter Table-Objekt korrekt akzeptiert wird, sowie allgemeine Unterstützung für FromClause-Objekte als "selectable"-Argument, da dies alles unterstützt wird.

  Referenzen: #10061

postgresql

• [postgresql] [usecase]

  Unterstützung für mehrere Hosts für den asyncpg-Dialekt hinzugefügt. Allgemeine Verbesserungen und Fehlerprüfungen wurden zu den PostgreSQL-URL-Routinen für den "Multihost"-Anwendungsfall hinzugefügt. Pull-Request von Ilia Dmitriev.

  Siehe auch

  Multihost Connections

  Referenzen: #10004

• [postgresql] [bug]

  Neuer Parameter native_inet_types=False zu allen PostgreSQL-Dialekten hinzugefügt, der angibt, dass Konverter, die vom DBAPI zur Konvertierung von Zeilen aus PostgreSQL INET und CIDR-Spalten in Python ipaddress-Datentypen verwendet werden, deaktiviert werden sollten, und stattdessen Strings zurückgegeben werden. Dies ermöglicht die Migration von Code, der für diese Datentypen Strings verwendet, zu asyncpg, psycopg oder pg8000 ohne Codeänderungen, abgesehen vom Hinzufügen dieses Parameters zur Funktion create_engine() oder create_async_engine().

  Siehe auch

  Network Data Types

  Referenzen: #9945

mariadb

• [mariadb] [usecase] [reflection]

  Das Reflektieren von UUID-Spalten aus MariaDB wurde ermöglicht. Dies ermöglicht es Alembic, den Typ solcher Spalten in vorhandenen MariaDB-Datenbanken korrekt zu erkennen.

  Referenzen: #10028

mssql

• [mssql] [usecase]

  Unterstützung für die Erstellung und Reflexion von COLUMNSTORE-Indizes im MSSQL-Dialekt hinzugefügt. Kann bei Indizes mit mssql_columnstore=True angegeben werden.

  Referenzen: #7340

• [mssql] [bug] [sql]

  Behobenes Problem, bei dem das Casten zu einem String-Typ mit einer expliziten Kollation die COLLATE-Klausel innerhalb der CAST-Funktion gerendert hat, was zu einem Syntaxfehler führte.

  Referenzen: #9932

2.0.17

Veröffentlicht: 23. Juni 2023

orm

• [orm] [bug] [regression]

  Behobene Regression in der Serie 2.0, bei der eine Abfrage, die undefer_group() mit selectinload() oder subqueryload() verwendete, einen AttributeError auslöste. Pull-Request von Matthew Martin.

  Referenzen: #9870

• [orm] [bug]

  Behobenes Problem in der ORM Annotated Declarative, das die Verwendung eines declared_attr in einem Mixin verhinderte, das keinen Mapped-Datentyp zurückgab, sondern stattdessen einen ergänzenden ORM-Datentyp wie AssociationProxy zurückgab. Die Declarative-Laufzeit versuchte fälschlicherweise, diese Annotation als zu mappend zu interpretieren und löste einen Fehler aus.

  Referenzen: #9957

• [orm] [bug] [typing]

  Behobenes Typisierungs Problem, bei dem der Rückgabetyp von AssociationProxy aus einer declared_attr-Funktion nicht zulässig war.

  Referenzen: #9957

• [orm] [bug] [regression]

  Behobene Regression, die in 2.0.16 durch #9879 eingeführt wurde, bei der die Übergabe eines Callables an den Parameter mapped_column.default von mapped_column, während gleichzeitig init=False gesetzt war, diesen Wert als Dataclass-Standardwert interpretierte, der direkt neuen Instanzen des Objekts zugewiesen wurde und dabei den Standardgenerator umging, der als Wert von Column.default auf der zugrunde liegenden Column wirkte. Diese Bedingung wird nun erkannt, sodass das vorherige Verhalten beibehalten wird; es wird jedoch eine Deprecation-Warnung für diese mehrdeutige Verwendung ausgegeben; um den Standardgenerator für eine Column zu füllen, sollte der Parameter mapped_column.insert_default verwendet werden, der vom Parameter mapped_column.default, dessen Name gemäß pep-681 korrigiert wurde, abgegrenzt wird.

  Referenzen: #9936

• [orm] [bug]

  Zusätzliche Absicherung und Dokumentation für das "state change"-System der ORM Session, das die gleichzeitige Verwendung von Session- und AsyncSession-Objekten erkennt; eine zusätzliche Prüfung wird im Prozess zur Beschaffung von Verbindungen aus der zugrunde liegenden Engine hinzugefügt, was ein kritischer Abschnitt in Bezug auf das interne Verbindungsmanagement ist.

  Referenzen: #9973

• [orm] [bug]

  Behobenes Problem in der ORM-Lade-Strategie, das längere Ketten von contains_eager()-Ladeoptionen über komplexe, vererbende, polymorphe / aliasierte / of_type()-Beziehungsketten hinweg ermöglicht, damit diese in Abfragen korrekt wirksam werden.

  Referenzen: #10006

• [orm] [bug]

  Behobenes Problem bei der Unterstützung des Enum-Datentyps in der registry.type_annotation_map, die erstmals im Rahmen von #8859 hinzugefügt wurde. Dabei schlug die Verwendung eines benutzerdefinierten Enum mit fester Konfiguration in der Map fehl, den Enum.name-Parameter zu übertragen, was unter anderem dazu führte, dass PostgreSQL-Enums nicht funktionierten, wenn die Enum-Werte als einzelne Werte übergeben wurden. Die Logik wurde aktualisiert, sodass "name" übertragen wird, aber auch, dass der Standard-Enum, der gegen die reine Python-Klasse enum.Enum oder eine andere "leere" Enum gerichtet ist, keinen hartkodierten Namen von "enum" setzt.

  Referenzen: #9963

orm declarative

• [orm] [declarative] [bug]

  Eine Warnung wird ausgegeben, wenn ein ORM relationship() und andere MapperProperty-Objekte gleichzeitig zwei verschiedenen Klassenattributen zugewiesen werden; nur eines der Attribute wird gemappt. Eine Warnung für diesen Zustand gab es bereits für Column und mapped_column-Objekte.

  Referenzen: #3532

extensions

• [extensions] [bug]

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

  Diese Änderung wird auch zurückportiert nach: 1.4.49

typing

• [typing] [bug]

  Behobenes Typisierungs Problem, das die vollständige Verwendung von WriteOnlyMapped- und DynamicMapped-Attributen in ORM-Abfragen verhinderte.

  Referenzen: #9985

postgresql

• [postgresql] [usecase]

  Der pg8000-Dialekt unterstützt nun RANGE- und MULTIRANGE-Datentypen, wobei die vorhandene RANGE-API verwendet wird, die unter Range and Multirange Types beschrieben ist. Bereichs- und Multibereichstypen werden im pg8000-Treiber ab Version 1.29.8 unterstützt. Pull-Request von Tony Locke.

  Referenzen: #9965

2.0.16

Veröffentlicht: 10. Juni 2023

platform

• [platform] [usecase]

  Kompatibilitätsverbesserungen, die es dem vollständigen Test-Suite ermöglichen, auf Python 3.12.0b1 zu bestehen.

orm

• [orm] [usecase]

  Verbesserte `DeferredReflection.prepare()` so, dass sie beliebige `**kw`-Argumente akzeptiert, die an `MetaData.reflect()` übergeben werden, was Anwendungsfälle wie die Reflexion von Views sowie Dialekt-spezifische Argumente ermöglicht. Zusätzlich wurde das Argument `DeferredReflection.prepare.bind` modernisiert, sodass entweder eine `Engine` oder `Connection` als "bind"-Argument akzeptiert werden.

  Referenzen: #9828

• [orm] [bug]

  Behobenes Problem, bei dem die deklarative Basisklasse `DeclarativeBaseNoMeta` nicht mit nicht gemappten Mixins oder abstrakten Klassen funktionierte und stattdessen einen `AttributeError` auslöste.

  Referenzen: #9862

• [orm] [bug] [regression]

  Behobene Regression in der Serie 2.0, bei der der Standardwert von `validates.include_backrefs` für die Funktion `validates()` auf `False` geändert wurde. Dieser Standardwert wird nun wieder auf `True` gesetzt.

  Referenzen: #9820

• [orm] [bug]

  Behobener Fehler in der neuen Funktion, die es ermöglicht, eine WHERE-Klausel mit dem ORM Bulk UPDATE nach Primärschlüssel zu verwenden, das in Version 2.0.11 im Rahmen von #9583 hinzugefügt wurde. Zuvor wurden Dictionaries, die nicht die Primärschlüsselwerte für jede Zeile enthielten, über den Bulk-Prozess ausgeführt und schlossen "pk=NULL" für die Zeilen ein, was stillschweigend fehlschlug. Nun wird eine Ausnahme ausgelöst, wenn keine Primärschlüsselwerte für Bulk-UPDATE angegeben werden.

  Referenzen: #9917

• [orm] [bug] [dataclasses]

  Behobenes Problem, bei dem die Generierung von Dataclass-Feldern, die einen `default`-Wert angaben und `init=False` gesetzt hatten, nicht funktionierte. Das Verhalten von Dataclasses in diesem Fall ist, den Standardwert auf der Klasse zu setzen, was nicht mit den von SQLAlchemy verwendeten Deskriptoren kompatibel ist. Um diesen Fall zu unterstützen, wird der Standardwert bei der Generierung des Dataclass in einen `default_factory` umgewandelt.

  Referenzen: #9879

• [orm] [bug]

  Eine Deprecation-Warnung wird ausgegeben, wenn eine Eigenschaft zu einem `Mapper` hinzugefügt wird, bei dem bereits eine ORM-gemappte Eigenschaft konfiguriert ist oder ein Attribut bereits auf der Klasse vorhanden ist. Zuvor gab es für diesen Fall eine nicht-Deprecation-Warnung, die nicht konsistent ausgegeben wurde. Die Logik für diese Warnung wurde verbessert, sodass sie das Ersetzen von Attributen durch Endbenutzer erkennt, ohne falsche positive Ergebnisse für interne Declarative und andere Fälle zu haben, in denen das Ersetzen von Deskriptoren durch neue erwartet wird.

  Referenzen: #9841

• [orm] [bug]

  Verbesserte Argumentprüfung für den Parameter `map_imperatively.local_table` der Methode `registry.map_imperatively()`, um sicherzustellen, dass nur eine `Table` oder eine andere `FromClause` übergeben wird und keine bereits gemappte Klasse, was zu undefiniertem Verhalten führen würde, da das Objekt für eine neue Mappung weiter interpretiert wird.

  Referenzen: #9869

• [orm] [bug]

  Das Attribut `InstanceState.unloaded_expirable` ist ein Synonym für `InstanceState.unloaded` und ist nun veraltet; dieses Attribut war schon immer implementierungsspezifisch und hätte nicht öffentlich sein sollen.

  Referenzen: #9913

asyncio

• [asyncio] [usecase]

  Neuer Parameter `create_async_engine.async_creator` zu `create_async_engine()` hinzugefügt, der denselben Zweck erfüllt wie der Parameter `create_engine.creator` von `create_engine()`. Dies ist ein aufrufloser Aufruf, der eine neue asyncio-Verbindung bereitstellt und den asynchronen Treiber auf Treiberebene direkt verwendet. Die Funktion `create_async_engine()` wird die treiberseitige Verbindung in die entsprechenden Strukturen verpacken. Pull-Request von Jack Wotherspoon.

  Referenzen: #8215

postgresql

• [postgresql] [usecase] [reflection]

  NAME-Spalten werden beim Verwenden von `ARRAY_AGG` in der PostgreSQL-Reflexion auf `TEXT` gecastet. Dies scheint die Kompatibilität mit einigen PostgreSQL-Derivaten zu verbessern, die Aggregationen auf dem NAME-Typ möglicherweise nicht unterstützen.

  Referenzen: #9838

• [postgresql] [usecase]

  Die benutzerdefinierten PostgreSQL-Operatordefinitionen wurden vereinheitlicht, da sie zwischen mehreren verschiedenen Datentypen geteilt werden.

  Referenzen: #9041

• [postgresql] [usecase]

  Unterstützung für die PostgreSQL 10 `NULLS NOT DISTINCT`-Funktion von eindeutigen Indizes und eindeutigen Constraints wurde über die Dialektoption `postgresql_nulls_not_distinct` hinzugefügt. Die Reflexionslogik wurde aktualisiert, um diese Option ebenfalls korrekt zu berücksichtigen. Pull-Request von Pavel Siarchenia.

  Referenzen: #8240

• [postgresql] [bug]

  Korrekte Präzedenz für PostgreSQL-spezifische Operatoren wie `@>` verwendet. Zuvor war die Präzedenz falsch, was zu falschen Klammern bei der Wiedergabe gegen eine `ANY`- oder `ALL`-Konstruktion führte.

  Referenzen: #9836

• [postgresql] [bug]

  Behobenes Problem, bei dem die Parameter `ColumnOperators.like.escape` und ähnliche Parameter keinen leeren String als Argument zuließen, der als "escape"-Zeichen weitergegeben würde; dies ist eine von PostgreSQL unterstützte Syntax. Pull-Request von Martin Caslavsky.

  Referenzen: #9907

2.0.15

Veröffentlicht: 19. Mai 2023

orm

• [orm] [bug]

  Da immer mehr Projekte die neuen "2.0"-ORM-Abfragen verwenden, wird deutlich, dass die bedingte Natur von "autoflush", die darauf basiert, ob die gegebene Anweisung ORM-Entitäten referenziert, immer wichtiger wird. Bis jetzt basierte das "ORM"-Flag für eine Anweisung lose darauf, ob die Anweisung Zeilen zurückgibt, die ORM-Entitäten oder -Spalten entsprechen; der ursprüngliche Zweck des "ORM"-Flags war es, ORM-Entitäts-Fetching-Regeln zu ermöglichen, die Post-Processing auf Core-Ergebnis-Sets sowie ORM-Lader-Strategien auf die Anweisung anwenden. Für Anweisungen, die nicht auf Zeilen basieren, die ORM-Entitäten enthalten, galt das "ORM"-Flag als weitgehend unnötig.

  Es mag immer noch der Fall sein, dass "autoflush" für *alle* Verwendungen von `Session.execute()` und verwandten Methoden besser greifen würde, selbst für rein Core-SQL-Konstrukte. Dies könnte jedoch immer noch Legacy-Fälle beeinträchtigen, bei denen dies nicht erwartet wird und eher eine Sache für 2.1 ist. Vorerst wurden jedoch die Regeln für das "ORM-Flag" erweitert, sodass eine Anweisung, die ORM-Entitäten oder -Attribute irgendwo enthält, einschließlich allein in der WHERE- / ORDER-BY- / GROUP-BY-Klausel, in skalar-Subqueries usw., dieses Flag aktiviert. Dies bewirkt, dass "autoflush" für solche Anweisungen auftritt und auch über das Ereignisattribut `ORMExecuteState.is_orm_statement` sichtbar ist.

  Referenzen: #9805

postgresql

• [postgresql] [bug] [regression]

  Reparierte den Basis-Datentyp Uuid für das PostgreSQL-Dialekt, um den PG-spezifischen UUID-Datentyp vollständig zu nutzen, wenn "native_uuid" ausgewählt ist, sodass PG-Treiberverhalten einbezogen werden. Dieses Problem wurde durch die Verbesserung von insertmanyvalues im Rahmen von #9618 deutlich, bei der der asyncpg-Treiber, ähnlich wie bei #9739, sehr empfindlich auf das Vorhandensein oder Nichtvorhandensein von Datentyp-K överläufen reagiert. Der native UUID-Datentyp des PostgreSQL-Treibers muss aufgerufen werden, wenn dieser generische Typ verwendet wird, damit diese K överläufe stattfinden.

  Referenzen: #9808

2.0.14

Veröffentlicht: 18. Mai 2023

orm

• [orm] [bug]

  Die Implementierung von JoinedLoader wurde modifiziert, um einen einfacheren Ansatz in einem bestimmten Bereich zu verwenden, in dem zuvor eine zwischengespeicherte Struktur verwendet wurde, die zwischen Threads geteilt wurde. Das Ziel ist, eine potenzielle Race Condition zu vermeiden, die vermutlich die Ursache für einen bestimmten Absturz ist, der mehrfach gemeldet wurde. Die betreffende zwischengespeicherte Struktur wird über den kompilierten SQL-Cache letztendlich weiterhin "zwischengespeichert", sodass keine Leistungseinbußen erwartet werden.

  Referenzen: #9777

• [orm] [bug] [regression]

  Regression behoben, bei der die Verwendung von update() oder delete() innerhalb einer CTE-Konstruktion, die dann in einem select() verwendet wurde, einen CompileError auslöste. Dies war auf ORM-bezogene Regeln für die Ausführung von UPDATE/DELETE-Anweisungen auf ORM-Ebene zurückzuführen.

  Referenzen: #9767

• [orm] [bug]

  Problem behoben, bei dem bei Verwendung einer ForeignKey (oder einer anderen Constraint auf Spaltenebene) innerhalb von mapped_column() im neuen ORM Annotated Declarative, die dann über pep-593 Annotated in Modelle kopiert wurde, Duplikate jeder Constraint auf die Column angewendet wurden, wie sie in der Ziel-Table erstellt wurde. Dies führte zu fehlerhaftem CREATE TABLE DDL sowie zu Migrationsanweisungen unter Alembic.

  Referenzen: #9766

• [orm] [bug]

  Problem behoben, bei dem zusätzliche Kriteriën für Beziehungen mit der Ladeoption joinedload(), wobei die zusätzlichen Kriteriën selbst korrelierte Unterabfragen enthielten, die sich auf die geladenen Entitäten bezogen und daher auch eine "Anpassung" an aliasierte Entitäten erforderten, von dieser Anpassung ausgeschlossen wurden, was zu einer falschen ON-Klausel für joinedload führte.

  Referenzen: #9779

sql

• [sql] [usecase]

  Die MSSQL-Funktion try_cast() wurde in den Import-Namensraum sqlalchemy. verallgemeinert, damit sie auch von Drittanbieter-Dialekten implementiert werden kann. Innerhalb von SQLAlchemy bleibt die Funktion try_cast() ein reines SQL Server-Konstrukt, das einen CompileError auslöst, wenn es mit Backends verwendet wird, die es nicht unterstützen.

  try_cast() implementiert eine CAST, bei der nicht konvertierbare Konvertierungen als NULL zurückgegeben werden, anstatt einen Fehler auszulösen. Theoretisch könnte das Konstrukt von Drittanbieter-Dialekten für Google BigQuery, DuckDB und Snowflake sowie möglicherweise andere implementiert werden.

  Pull-Request dank Nick Crews.

  Referenzen: #9752

• [sql] [bug]

  Problem im values()-Konstrukt behoben, bei dem ein interner Kompilierungsfehler auftrat, wenn das Konstrukt innerhalb einer skalaren Unterabfrage verwendet wurde.

  Referenzen: #9772

postgresql

• [postgresql] [bug]

  Ein offenbar sehr altes Problem behoben, bei dem der Parameter ENUM.create_type, wenn er auf seinen Nicht-Standardwert False gesetzt war, nicht weitergegeben wurde, wenn die Column, zu der er gehörte, kopiert wurde, wie es bei der Verwendung von ORM Declarative Mixins üblich ist.

  Referenzen: #9773

tests

• [tests] [bug] [pypy]

  Ein Test behoben, der darauf angewiesen war, dass die Funktion sys.getsizeof() unter pypy nicht ausgeführt wird, da diese Funktion anscheinend ein anderes Verhalten aufweist als unter cpython.

  Referenzen: #9789

2.0.13

Veröffentlicht: 10. Mai 2023

orm

• [orm] [bug]

  Problem behoben, bei dem ORM Annotated Declarative Vorwärtsreferenzen nicht in allen Fällen korrekt auflöste; insbesondere bei Verwendung von from __future__ import annotations in Kombination mit Pydantic Dataclasses.

  Referenzen: #9717

• [orm] [bug]

  Problem in der neuen Verwendung von RETURNING mit Upsert-Anweisungen behoben, bei der die Ausführungsoption populate_existing nicht an die Ladeoption weitergegeben wurde, was verhinderte, dass bestehende Attribute vor Ort aktualisiert wurden.

  Referenzen: #9746

• [orm] [bug]

  Probleme mit dem Pfad von Lade-Strategien behoben, bei denen Eager-Loader wie joinedload() / selectinload() bei vielen verschachtelten Ebenen nach einem Ladevorgang, der with_polymorphic() oder ähnliche Konstrukte als Zwischenmitglied hatte, nicht vollständig durchlaufen konnten, was zu fehlerhaften ON-Klauseln für joinedload führte.

  Referenzen: #9715

• [orm] [bug]

  Problem im Konstrukt mapped_column() behoben, bei dem die korrekte Warnung für "Spalte X mehrmals direkt benannt" nicht ausgegeben wurde, wenn ORM-zugeordnete Attribute auf dieselbe Column verwiesen, wenn das Konstrukt mapped_column() beteiligt war, stattdessen eine interne Assertion ausgelöst wurde.

  Referenzen: #9630

sql

• [sql] [usecase]

  Die "Cartesian Product Warning" für UPDATE- und DELETE-Anweisungen implementiert, die mehrere Tabellen enthalten, die nicht auf irgendeine Weise miteinander korreliert sind.

  Referenzen: #9721

• [sql] [bug]

  Die Basisklasse für dialektspezifische Float/Double-Typen behoben; Oracle BINARY_DOUBLE erbt nun von Double, und interne Typen für Float für asyncpg und pg8000 erben nun korrekt von Float.

• [sql] [bug]

  Problem behoben, bei dem ein update()-Konstrukt, das mehrere Tabellen und keine VALUES-Klausel enthielt, mit einem internen Fehler ausgelöst wurde. Das aktuelle Verhalten für Update ohne Werte ist die Generierung einer SQL UPDATE-Anweisung mit einer leeren "set"-Klausel, sodass dies für diesen speziellen Unterfall konsistent gemacht wurde.

schema

• [schema] [performance]

  Verbessert, wie Tabellenspalten hinzugefügt werden, unnötige Allokationen werden vermieden, was die Erstellung vieler Tabellen erheblich beschleunigt, z. B. beim Reflektieren ganzer Schemata.

  Referenzen: #9597

typing

• [typing] [bug]

  Typisierung für den Parameter Session.get.with_for_update von Session.get() und Session.refresh() (sowie entsprechende Methoden auf AsyncSession) verbessert, um boolesches True und alle anderen Argumentformen zu akzeptieren, die der Parameter zur Laufzeit akzeptiert.

  Referenzen: #9762

• [typing] [sql]

  Der Typ ColumnExpressionArgument wurde als öffentlich zugänglicher Typ hinzugefügt, der spaltenorientierte Argumente angibt, die an SQLAlchemy-Konstrukte übergeben werden, wie z. B. Select.where(), and_() und andere. Dies kann verwendet werden, um benutzerdefinierte Funktionen, die diese Methoden aufrufen, mit Typen zu versehen.

  Referenzen: #9656

asyncio

• [asyncio] [usecase]

  Ein neuer Hilfs-Mixin AsyncAttrs wurde hinzugefügt, der die Verwendung von Lazy-Loadern und anderen abgelaufenen oder verzögerten ORM-Attributen mit asyncio verbessern soll. Er bietet einen einfachen Attribut-Accessor, der eine await-Schnittstelle zu jedem ORM-Attribut bietet, unabhängig davon, ob SQL emittiert werden muss oder nicht.

  Siehe auch

  AsyncAttrs

  Referenzen: #9731

• [asyncio] [bug]

  Problem in den semi-privaten Concurrency-Funktionen await_only() und await_fallback() behoben, bei denen das gegebene Awaitable nicht awaited wurde, wenn die Funktion einen GreenletError auslöste, was später zu Warnungen über "nicht awaited" führen konnte, wenn das Programm fortgesetzt wurde. In diesem Fall wird das gegebene Awaitable nun abgebrochen, bevor die Ausnahme ausgelöst wird.

postgresql

• [postgresql] [bug] [regression]

  Eine weitere Regression aufgrund der Änderung "insertmanyvalues" in 2.0.10 im Rahmen von #9618 behoben. Ähnlich wie bei der Regression #9701 müssen LargeBinary-Datentypen bei Verwendung des asyncpg-Treibers speziell zusätzliche K överläufe aufweisen, um mit dem neuen Bulk-INSERT-Format zu funktionieren.

  Referenzen: #9739

oracle

• [oracle] [reflection]

  Unterstützung für die Reflexion von ausgedruckten Indizes und die Sortierrichtung von Indexausdrücken im Oracle-Dialekt hinzugefügt.

  Referenzen: #9597

misc

• [bug] [ext]

  Problem mit Mutable behoben, bei dem die Ereignisregistrierung für ORM-zugeordnete Attribute für Unterklassen mit zugeordneter Vererbung wiederholt aufgerufen wurde, was zu doppelten Ereignissen in Vererbungshierarchien führte.

  Referenzen: #9676

2.0.12

Veröffentlicht: 30. April 2023

orm

• [orm] [bug]

  Kritische Caching-Problematik behoben, bei der die Kombination aus aliased() und hybrid_property()-Ausdruckskombinationen zu einem Cache-Schlüssel-Mismatch führten, was dazu führte, dass Cache-Schlüssel das eigentliche aliased()-Objekt enthielten und gleichzeitig nicht mit äquivalenten Konstrukten übereinstimmten, was den Cache auffüllte.

  Diese Änderung wird auch zurückportiert auf: 1.4.48

  Referenzen: #9728

mysql

• [mysql] [bug] [mariadb]

  Probleme bei der Reflexion von Kommentaren für Table- und Column-Objekten behoben, bei denen die Kommentare Steuerzeichen wie Zeilenumbrüche enthielten. Zusätzliche Testunterstützung für diese Zeichen sowie für erweiterte Unicode-Zeichen in Tabellen- und Spaltenkommentaren (letztere werden von MySQL/MariaDB nicht unterstützt) wurde zum Testen insgesamt hinzugefügt.

  Referenzen: #9722

2.0.11

Veröffentlicht: 26. April 2023

orm

• [orm] [usecase]

  Die Funktionen für ORM Bulk INSERT und UPDATE fügen nun diese Möglichkeiten hinzu

  • Die Anforderung, dass keine zusätzlichen Parameter übergeben werden, wenn ORM INSERT mit der Einstellung "orm" für dml_strategy verwendet wird, ist aufgehoben.

  • Die Anforderung, dass keine zusätzlichen WHERE-Kriterien übergeben werden, wenn ORM UPDATE mit der Einstellung "bulk" für dml_strategy verwendet wird, ist aufgehoben. Beachten Sie, dass in diesem Fall die Prüfung auf die erwartete Zeilenanzahl deaktiviert ist.

  Referenzen: #9583, #9595

• [orm] [bug]

  2.0-Regression behoben, bei der die Verwendung von bindparam() innerhalb von Insert.values() nicht korrekt interpretiert wurde, wenn die Insert-Anweisung über die ORM Session ausgeführt wurde. Dies lag daran, dass das neue Feature ORM-fähiger Insert diesen Anwendungsfall nicht implementierte.

  Referenzen: #9583, #9595

engine

• [engine] [performance]

  Eine Reihe von Leistungsverbesserungen für Row

  • Die Leistung von __getattr__ des "Named Tuple"-Interfaces der Zeile wurde verbessert; innerhalb dieser Änderung wurde die Implementierung von Row gestrafft, indem Konstrukte und Logik entfernt wurden, die spezifisch für die 1.4er und frühere SQLAlchemy-Versionen waren. Als Teil dieser Änderung wurde das Serialisierungsformat von Row leicht modifiziert, wobei Zeilen, die mit früheren SQLAlchemy 2.0-Releases gepickelt wurden, im neuen Format erkannt werden. Pull-Request dank J. Nick Koston.

  • Die Leistung der Zeilenverarbeitung für "binäre" Datentypen wurde verbessert, indem der "bytes"-Handler treiberseitig bedingt gemacht wurde. Als Ergebnis wurde der "bytes"-Ergebnisbehandler für fast alle Treiber außer psycopg2 entfernt, die alle in modernen Formen Python-"bytes" direkt zurückgeben können. Pull-Request dank J. Nick Koston.

  • Weitere Refaktorierungen innerhalb von Row zur Leistungsverbesserung durch Federico Caselli.

  Referenzen: #9678, #9680

• [engine] [bug] [regression]

  Regression behoben, die die Funktionalität des Attributs URL.normalized_query von URL verhinderte.

  Referenzen: #9682

sql

• [sql] [usecase]

  Unterstützung für Slice-Zugriff mit ColumnCollection hinzugefügt, z.B. table.c[0:5], subquery.c[:-1] etc. Slice-Zugriff gibt eine Unter-ColumnCollection auf dieselbe Weise zurück wie die Übergabe eines Tupels von Schlüsseln. Dies ist eine natürliche Fortsetzung des Schlüssel-Tupel-Zugriffs, der für #8285 hinzugefügt wurde, wobei es ein Versehen zu sein scheint, dass der Slice-Zugriffs-Anwendungsfall ausgelassen wurde.

  Referenzen: #8285

typing

• [typing] [bug]

  Typisierung von RowMapping verbessert, um anzuzeigen, dass sie auch Column als Indexobjekte unterstützt, nicht nur Zeichenkettennamen. Pull-Request dank Andy Freeland.

  Referenzen: #9644

postgresql

• [postgresql] [bug] [regression]

  Kritische Regression behoben, die durch #9618 verursacht wurde, welche die Architektur des insertmanyvalues Features für 2.0.10 modifizierte. Dies führte dazu, dass Gleitkommazahlen alle Dezimalstellen verloren, wenn sie mit dem insertmanyvalues-Feature mit den Treibern psycopg2 oder psycopg eingefügt wurden.

  Referenzen: #9701

mssql

• [mssql] [bug]

  Der Typ Double für SQL Server implementiert, wo er zur DDL-Zeit als DOUBLE PRECISION gerendert wird. Dies wird unter Verwendung eines neuen MSSQL-Datentyps DOUBLE_PRECISION implementiert, der auch direkt verwendet werden kann.

oracle

• [oracle] [bug]

  Problem in Oracle-Dialekten behoben, bei dem von Decimal zurückgebende Typen wie Numeric Gleitkommazahlen zurückgaben, anstatt Decimal-Objekte, wenn diese Spalten in der Klausel Insert.returning() verwendet wurden, um eingefügte Werte zurückzugeben.

2.0.10

Veröffentlicht: 21. April 2023

orm

• [orm] [bug]

  Behobener Fehler, bei dem verschiedene ORM-spezifische Getter wie ORMExecuteState.is_column_load, ORMExecuteState.is_relationship_load, ORMExecuteState.loader_strategy_path usw. einen AttributeError auslösten, wenn die SQL-Anweisung selbst ein „zusammengesetztes Select“ wie UNION war.

  Diese Änderung wird auch zurückportiert auf: 1.4.48

  Referenzen: #9634

• [orm] [bug]

  Behobenes Problem, bei dem der Modifikator declared_attr.directive() für Unterklassen nicht korrekt beachtet wurde, wenn er auf den speziellen Methodennamen __mapper_args__ angewendet wurde, im Gegensatz zur direkten Verwendung von declared_attr. Die beiden Konstrukte sollten identisches Laufzeitverhalten aufweisen.

  Referenzen: #9625

• [orm] [bug]

  Verbesserung an der Loader-Option with_loader_criteria(), um sie in der Methode Executable.options() einer übergeordneten Anweisung angeben zu können, die selbst keine ORM-Anweisung ist. Beispiele hierfür sind select(), das in zusammengesetzten Anweisungen wie union() eingebettet ist, innerhalb eines Insert.from_select()-Konstrukts sowie innerhalb von CTE-Ausdrücken, die auf oberster Ebene nicht ORM-bezogen sind.

  Referenzen: #9635

• [orm] [bug]

  Behobener Fehler bei der ORM-Massen-Einfügung, bei dem zusätzliche unnötige Spalten in der INSERT-Anweisung gerendert wurden, wenn das Zurückgeben einzelner Spalten angefordert wurde.

  Referenzen: #9685

• [orm] [bug]

  Behobener Fehler bei ORM Declarative Dataclasses, bei dem die Konstrukte query_expression() und column_property(), die im Kontext eines Declarative-Mappings als schreibgeschützte Konstrukte dokumentiert sind, nicht mit einer MappedAsDataclass-Klasse verwendet werden konnten, ohne init=False hinzuzufügen, was im Fall von query_expression() nicht möglich war, da kein init-Parameter enthalten war. Diese Konstrukte wurden aus Sicht von Dataclasses so geändert, dass sie standardmäßig als „schreibgeschützt“ gelten, init=False standardmäßig setzen und nicht mehr in den pep-681-Konstruktor aufgenommen werden. Die Dataclass-Parameter für column_property() init, default, default_factory, kw_only sind nun veraltet; diese Felder gelten nicht für column_property() in einer Declarative-Dataclasses-Konfiguration, in der das Konstrukt schreibgeschützt wäre. Außerdem wurde der schreibgeschützte Parameter query_expression.compare zu query_expression() hinzugefügt; query_expression.repr war bereits vorhanden.

  Referenzen: #9628

• [orm] [bug]

  Fehlender Parameter mapped_column.active_history zum Konstrukt mapped_column() hinzugefügt.

engine

• [engine] [usecase]

  Hinzugefügt wurden create_pool_from_url() und create_async_pool_from_url(), um eine Pool-Instanz aus einer als String oder URL übergebenen Eingabe-URL zu erstellen.

  Referenzen: #9613

• [engine] [bug]

  Behobener erheblicher Mangel, der bei der Leistungsoptimierungsfunktion „Insert Many Values“-Verhalten für INSERT-Anweisungen für INSERT-Anweisungen festgestellt wurde, die zuerst in der 2.0-Serie eingeführt wurde. Dies war eine Fortsetzung der Änderung in 2.0.9, die die SQL Server-Version der Funktion deaktivierte, da sie sich auf eine scheinbare Zeilenreihenfolge im ORM verließ, die nicht garantiert ist. Die Korrektur wendet eine neue Logik auf alle „insertmanyvalues“-Operationen an, die wirksam wird, wenn ein neuer Parameter Insert.returning.sort_by_parameter_order in den Methoden Insert.returning() oder UpdateBase.return_defaults(), die durch eine Kombination aus alternativen SQL-Formen, direkter Entsprechung von Client-seitigen Parametern und in einigen Fällen Downgrading auf zeilenweises Ausführen, die Sortierung jeder Charge von zurückgegebenen Zeilen unter Verwendung der Entsprechung mit Primärschlüsseln oder anderen eindeutigen Werten in jeder Zeile, die mit den Eingabedaten korreliert werden kann, anwenden wird.

  Die Leistungsauswirkungen werden voraussichtlich minimal sein, da fast alle gängigen Primärschlüsselszenarien für die parametergeordnete Stapelverarbeitung für alle Backends außer SQLite geeignet sind, während der „zeilenweise“-Modus mit einem Mindestmaß an Python-Overhead im Vergleich zu den sehr aufwändigen Ansätzen der 1.x-Serie arbeitet. Für SQLite gibt es keine Leistungsunterschiede, wenn der „zeilenweise“-Modus verwendet wird.

  Es wird erwartet, dass mit einer effizienten zeilenweisen INSERT-mit-RETURNING-Stapelverarbeitung die „insertmanyvalues“-Funktion später einfacher auf Drittanbieter-Backends verallgemeinert werden kann, die RETURNING-Unterstützung bieten, aber nicht unbedingt einfache Möglichkeiten, eine Entsprechung mit der Parameterreihenfolge zu gewährleisten.

  Siehe auch

  Korrelation von RETURNING-Zeilen zu Parametersätzen

  Referenzen: #9603, #9618

typing

• [typing] [bug]

  Typisierungsinformationen für kürzlich hinzugefügte Operatoren ColumnOperators.icontains(), ColumnOperators.istartswith(), ColumnOperators.iendswith() und bitweise Operatoren ColumnOperators.bitwise_and(), ColumnOperators.bitwise_or(), ColumnOperators.bitwise_xor(), ColumnOperators.bitwise_not(), ColumnOperators.bitwise_lshift() ColumnOperators.bitwise_rshift() hinzugefügt. Pull Request von Martijn Pieters.

  Referenzen: #9650

• [typing] [bug]

  Aktualisierungen des Codebestands, um die Typisierung mit Mypy 1.2.0 zu bestehen.

• [typing] [bug]

  Behobenes Typisierungsproblem, bei dem PropComparator.and_()-Ausdrücke innerhalb von Loader-Optionen wie selectinload() nicht korrekt typisiert wurden.

  Referenzen: #9669

postgresql

• [postgresql] [usecase]

  Option für das Verbindungsargument prepared_statement_name_func im asyncpg-Dialekt hinzugefügt. Diese Option ermöglicht die Übergabe eines aufrufbaren Objekts, das zur Anpassung des Namens der vorbereiteten Anweisung verwendet wird, die vom Treiber beim Ausführen von Abfragen erstellt wird. Pull Request von Pavel Sirotkin.

  Siehe auch

  Name der vorbereiteten Anweisung mit PGBouncer

  Referenzen: #9608

• [postgresql] [usecase]

  Fehlende Methode Range.intersection() hinzugefügt. Pull Request von Yurii Karabas.

  Referenzen: #9509

• [postgresql] [bug]

  Wiederherstellung des Parameters ENUM.name als optional in der Signatur für ENUM, da dieser automatisch aus einem gegebenen pep-435 Enum-Typ abgeleitet wird.

  Referenzen: #9611

• [postgresql] [bug]

  Behobenes Problem, bei dem der Vergleich von ENUM mit einem einfachen String den Typ der rechten Seite als VARCHAR umwandelte, was aufgrund expliziterer Umwandlungen, die in Dialekten wie asyncpg hinzugefügt wurden, zu einem PostgreSQL-Typenkonfliktfehler führte.

  Referenzen: #9621

• [postgresql] [bug]

  Behobenes Problem, das die Reflexion von ausdrucksbasierten Indizes mit langen Ausdrücken in PostgreSQL verhinderte. Der Ausdruck wurde fälschlicherweise auf die Identifikatorlänge (standardmäßig 63 Bytes) gekürzt.

  Referenzen: #9615

mssql

• [mssql] [bug]

  Die SQLAlchemy-Funktion „insertmanyvalues“, die schnelles INSERT von vielen Zeilen ermöglicht und auch RETURNING unterstützt, wurde vorübergehend für SQL Server deaktiviert. Da die Unit of Work derzeit auf dieser Funktion beruht, um vorhandene ORM-Objekte mit zurückgegebenen Primärschlüsselidentitäten abzugleichen, funktioniert dieses spezielle Anwendungsmuster nicht immer mit SQL Server, da die Reihenfolge der von „OUTPUT inserted“ zurückgegebenen Zeilen möglicherweise nicht immer mit der Reihenfolge übereinstimmt, in der die Tupel gesendet wurden, was dazu führt, dass das ORM falsche Entscheidungen über diese Objekte in nachfolgenden Operationen trifft.

  Siehe auch

  Korrelation von RETURNING-Zeilen zu Parametersätzen

  Referenzen: #9603, #9618

oracle

• [oracle] [bug]

  Behobenes Problem, bei dem der Uuid-Datentyp nicht in einer INSERT..RETURNING-Klausel mit dem Oracle-Dialekt verwendet werden konnte.

2.0.9

Veröffentlicht: 5. April 2023

orm

• [orm] [bug]

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

  Diese Änderung wird auch zurückportiert auf: 1.4.48

  Referenzen: #9590

mariadb

• [mariadb] [bug]

  row_number als reserviertes Wort in MariaDb hinzugefügt.

  Referenzen: #9588

mssql

• [mssql] [bug]

  Die SQLAlchemy-Funktion „insertmanyvalues“, die schnelle INSERT von vielen Zeilen ermöglicht und auch RETURNING unterstützt, ist vorübergehend für SQL Server deaktiviert. Da die Unit of Work derzeit auf dieser Funktion beruht, um vorhandene ORM-Objekte mit zurückgegebenen Primärschlüsselidentitäten abzugleichen, funktioniert dieses spezielle Anwendungsmuster nicht immer mit SQL Server, da die Reihenfolge der von „OUTPUT inserted“ zurückgegebenen Zeilen möglicherweise nicht immer mit der Reihenfolge übereinstimmt, in der die Tupel gesendet wurden, was dazu führt, dass das ORM falsche Entscheidungen über diese Objekte in nachfolgenden Operationen trifft.

  Die Funktion wird in einer zukünftigen Version wieder aktiviert und gilt wieder für Multi-Row-INSERT-Anweisungen, jedoch wird die Verwendung der Funktion durch die Unit-of-Work deaktiviert, möglicherweise für alle Dialekte, es sei denn, ORM-gemappte Tabellen enthalten auch eine „Sentinel“-Spalte, damit die zurückgegebenen Zeilen auf die ursprünglichen übergebenen Daten zurückgeführt werden können.

  Referenzen: #9603

• [mssql] [bug]

  Die Bulk-INSERT-Strategie für SQL Server „executemany“ mit pyodbc wurde geändert, wenn fast_executemany auf True gesetzt ist, indem fast_executemany / cursor.executemany() für Bulk-INSERTs ohne RETURNING verwendet wurde, wodurch das gleiche Verhalten wie in SQLAlchemy 1.4 wiederhergestellt wurde, wenn dieser Parameter gesetzt war.

  Neue Leistungsdetails von Endbenutzern haben gezeigt, dass fast_executemany für sehr große Datensätze immer noch wesentlich schneller ist, da es ODBC-Befehle verwendet, die alle Zeilen in einem einzigen Roundtrip empfangen können, was deutlich größere Datengrößen als die Batches ermöglicht, die von „insertmanyvalues“ gesendet werden können, wie es für SQL Server implementiert war.

  Obwohl diese Änderung vorgenommen wurde, damit „insertmanyvalues“ weiterhin für INSERTs mit RETURNING verwendet wird, sowie wenn fast_executemany nicht gesetzt war, wurde aufgrund von #9603 die „insertmanyvalues“-Strategie für SQL Server ohnehin generell deaktiviert.

  Referenzen: #9586

2.0.8

Veröffentlicht: 31. März 2023

orm

• [orm] [usecase]

  Ausnahmen wie TypeError und ValueError, die von Python-Dataclasses beim Verwenden der Mixin-Klasse MappedAsDataclass oder des Dekorators registry.mapped_as_dataclass() ausgelöst werden, werden nun in einen InvalidRequestError-Wrapper verpackt, zusammen mit informativen Kontexten zur Fehlermeldung, die auf die Dokumentation der Python-Dataclasses als maßgebliche Quelle für Hintergrundinformationen zur Ursache des Auslösens verweisen.

  Siehe auch

  Beim Erstellen einer Dataclass für <classname> aufgetretener Fehler bei Python-Dataclasses

  Referenzen: #9563

• [orm] [bug]

  Behobenes Problem bei ORM Annotated Declarative, bei dem die Verwendung eines rekursiven Typs (z. B. eines verschachtelten Dict-Typs) zu einem Rekursionsüberlauf in der Annotationsauflösungslogik des ORM führen konnte, selbst wenn dieser Datentyp nicht zum Mappen der Spalte erforderlich war.

  Referenzen: #9553

• [orm] [bug]

  Behobenes Problem, bei dem das Konstrukt mapped_column() einen internen Fehler auslöste, wenn es auf einer Declarative-Mixin verwendet und der Parameter mapped_column.deferred eingeschlossen wurde.

  Referenzen: #9550

• [orm] [bug]

  Die Warnung, die ausgegeben wird, wenn ein einfacher column()-Objekt in einem Declarative-Mapping vorhanden ist, wurde erweitert, um beliebige SQL-Ausdrücke einzuschließen, die nicht innerhalb eines geeigneten Eigenschaftstyps wie column_property(), deferred() usw. deklariert sind. Diese Attribute werden ansonsten überhaupt nicht gemappt und verbleiben unverändert im Klassenwörterbuch. Da es wahrscheinlich ist, dass ein solcher Ausdruck normalerweise nicht beabsichtigt ist, warnt dieser Fall nun für alle solchen ansonsten ignorierten Ausdrücke, anstatt nur für den Fall von column().

  Referenzen: #9537

• [orm] [bug]

  Behobene Regression, bei der der Zugriff auf den Ausdruckswert einer Hybrid-Eigenschaft einer Klasse, die entweder nicht gemappt oder noch nicht gemappt war (wie z. B. ein Aufruf innerhalb einer declared_attr()-Methode), einen internen Fehler auslöste, da ein interner Abruf des Mappers der übergeordneten Klasse fehlschlug und eine Anweisung zur Ignorierung dieses Fehlers in 2.0 versehentlich entfernt wurde.

  Referenzen: #9519

• [orm] [bug]

  Felder, die auf Declarative-Mixins deklariert und dann mit Klassen kombiniert werden, die MappedAsDataclass verwenden, wobei diese Mixin-Felder selbst keine Dataclass sind, geben nun eine Verwarnung aus, da diese Felder in einer zukünftigen Version ignoriert werden, da Python-Dataclasses-Verhalten diese Felder ignoriert. Typ-Checker sehen diese Felder unter pep-681 nicht.

  Siehe auch

  Beim Umwandeln von <cls> in eine Dataclass stammen Attribute von der Oberklasse <cls>, die keine Dataclass ist. - Hintergrund der Begründung

  Verwendung von Mixins und abstrakten Oberklassen

  Referenzen: #9350

• [orm] [bug]

  Behobenes Problem, bei dem die Methode BindParameter.render_literal_execute() fehlschlug, wenn sie auf einem Parameter aufgerufen wurde, der auch ORM-Annotationen zugeordnet hatte. In der Praxis würde sich dies als Kompilierungsfehler von SQL bemerkbar machen, wenn eine Kombination aus einem Dialekt, der „FETCH FIRST“ wie Oracle verwendet, zusammen mit einem Select-Konstrukt verwendet wird, das Select.limit() verwendet, innerhalb einiger ORM-Kontexte, einschließlich, wenn die Anweisung in einem Beziehung Primärschlüssel-Ausdruck eingebettet wäre.

  Referenzen: #9526

• [orm] [bug]

  Zur Beibehaltung der Konsistenz mit den Unit-of-Work-Änderungen für #5984 und #8862, die beide das „lazy='raise'“-Handling in Session-Prozessen deaktivieren, die nicht durch Attributzugriff ausgelöst werden, deaktiviert die Methode Session.delete() nun auch das „lazy='raise'“-Handling, wenn sie Beziehungspfade durchläuft, um die Kaskadenregeln „delete“ und „delete-orphan“ zu verarbeiten. Zuvor gab es keine einfache Möglichkeit, Session.delete() auf ein Objekt anzuwenden, das „lazy='raise'“ gesetzt hatte, sodass nur die notwendigen Beziehungen geladen würden. Da „lazy='raise'“ hauptsächlich dazu dient, SQL-Ladevorgänge zu erkennen, die beim Attributzugriff ausgelöst werden, verhält sich Session.delete() nun wie andere Session-Methoden, einschließlich Session.merge() sowie Session.flush() zusammen mit autoflush.

  Referenzen: #9549

• [orm] [bug]

  Behobenes Problem, bei dem eine reine Annotations-Mapped-Direktive nicht in einer Declarative-Mixin-Klasse verwendet werden konnte, ohne dass das Attribut für Einfach- oder Joined-Vererbungs-Unterklassen von gemappten Klassen, die das Attribut bereits auf einer Oberklasse gemappt hatten, wirksam wurde, was zu widersprüchlichen Spaltenfehlern und/oder Warnungen führte.

  Referenzen: #9564

• [orm] [bug] [typing]

  Korrekte Typisierung von Insert.from_select.names, um eine Liste von Zeichenketten oder Spalten oder gemappten Attributen zu akzeptieren.

  Referenzen: #9514

examples

• [examples] [bug]

  Behobenes Problem im Beispiel „versioned history“, bei dem die Verwendung einer deklarativen Basis, die von DeclarativeBase abgeleitet ist, nicht gemappt werden konnte. Außerdem wurde die gegebene Testsuite repariert, sodass die dokumentierten Anweisungen zum Ausführen des Beispiels mit Python unittest wieder funktionieren.

typing

• [typing] [bug]

  Typisierung für deferred() und query_expression() korrigiert, um korrekt mit 2.0-Style-Mappings zu funktionieren.

  Referenzen: #9536

postgresql

• [postgresql] [bug]

  Behobene kritische Regression in PostgreSQL-Dialekten wie asyncpg, die auf explizite Casts in SQL angewiesen sind, damit Datentypen korrekt an den Treiber übergeben werden. Dabei wurde ein String-Datentyp zusammen mit der exakten Spaltenlänge beim Vergleich maskiert, was zu einer impliziten Kürzung führte, wenn ein VARCHAR mit kürzerer Länge mit einem String größerer Länge verglichen wurde, unabhängig vom verwendeten Operator (z. B. LIKE, MATCH usw.). Der PostgreSQL-Dialekt verzichtet nun auf die Länge von VARCHAR bei der Darstellung dieser Casts.

  Referenzen: #9511

mysql

• [mysql] [bug]

  Problem behoben, bei dem Zeichenketten-Datentypen wie CHAR, VARCHAR, TEXT sowie binäre BLOB nicht mit einer expliziten Länge von Null erzeugt werden konnten, was für MySQL eine besondere Bedeutung hat. Pull-Request von J. Nick Koston.

  Referenzen: #9544

misc

• [bug] [util]

  Fehlende Methoden copy und pop in der Klasse OrderedSet implementiert.

  Referenzen: #9487

2.0.7

Veröffentlicht: 18. März 2023

typing

• [typing] [bug]

  Typisierungsproblem behoben, bei dem composite() keinen beliebigen Callable als Quelle der Composite-Klasse zuließ.

  Referenzen: #9502

postgresql

• [postgresql] [usecase]

  Neuer PostgreSQL-Typ CITEXT hinzugefügt. Pull-Request von Julian David Rath.

  Referenzen: #9416

• [postgresql] [usecase]

  Änderungen am Basis-PostgreSQL-Dialekt zur besseren Integration mit dem externen sqlalchemy-redshift-Dialekt für SQLAlchemy 2.0. Pull-Request von matthewgdv.

  Referenzen: #9442

2.0.6

Veröffentlicht: 13. März 2023

orm

• [orm] [bug]

  Fehler behoben, bei dem die Funktion "aktive Historie" für zusammengesetzte Attribute nicht vollständig implementiert war, was den Empfang von Ereignissen, die den "alten" Wert enthielten, unmöglich machte. Dies schien auch bei älteren SQLAlchemy-Versionen der Fall zu sein, bei denen "active_history" an die zugrundeliegenden spaltenbasierten Attribute weitergegeben wurde, ein Ereignis-Handler, der das zusammengesetzte Attribut selbst überwachte, jedoch nicht den ersetzten "alten" Wert erhielt, selbst wenn composite() mit active_history=True konfiguriert war.

  Zusätzlich wurde eine Regression behoben, die auf 2.0 beschränkt war und active_history für zusammengesetzte Attribute am impl mit attr.impl.active_history=True nicht zuließ.

  Referenzen: #9460

• [orm] [bug]

  Regression beim Pickling von Python-Zeilen zwischen den Cython- und reinen Python-Implementierungen von Row behoben, die als Teil der Refaktorisierung von Code für Version 2.0 mit Typisierung auftrat. Eine bestimmte Konstante wurde für die reine Python-Version von Row in ein stringbasiertes Enum umgewandelt, während die Cython-Version weiterhin eine ganzzahlige Konstante verwendete, was zu Deserialisierungsfehlern führte.

  Referenzen: #9418

sql

• [sql] [bug] [regression]

  Regression behoben, bei der die Korrektur für #8098, die in der 1.4-Serie veröffentlicht wurde und eine Schicht von nebenläufigkeitssicheren Prüfungen für die Lambda-SQL-API bereitstellte, zusätzliche Korrekturen im Patch enthielt, die nicht auf den Haupt-Branch angewendet wurden. Diese zusätzlichen Korrekturen wurden angewendet.

  Referenzen: #9461

• [sql] [bug]

  Regression behoben, bei der die select()-Konstruktion nicht gerendert werden konnte, wenn sie keine Spalten erhielt und dann im Kontext eines EXISTS verwendet wurde, was stattdessen eine interne Ausnahme auslöste. Obwohl ein leeres "SELECT" normalerweise kein gültiges SQL ist, erlauben Datenbanken wie PostgreSQL dies im Kontext von EXISTS, und in jedem Fall löst die Bedingung nun keine interne Ausnahme mehr aus.

  Referenzen: #9440

typing

• [typing] [bug]

  Typisierungsproblem behoben, bei dem ColumnElement.cast() kein TypeEngine-Argument unabhängig vom Typ des ColumnElement selbst zuließ, was der Zweck von ColumnElement.cast() ist.

  Referenzen: #9451

• [typing] [bug]

  Probleme behoben, damit Typisierungstests unter Mypy 1.1.1 erfolgreich sind.

oracle

• [oracle] [bug]

  Reflektionsfehler behoben, bei dem die "Namensnormalisierung" von Oracle für die Reflexion von Symbolen im Schema "PUBLIC" (wie Synonyme) nicht korrekt funktionierte, was bedeutete, dass der PUBLIC-Name auf der Python-Seite für das Argument Table.schema nicht als Kleinbuchstabe angegeben werden konnte. Die Verwendung von Großbuchstaben "PUBLIC" hätte funktioniert, aber zu umständlichen SQL-Abfragen geführt, einschließlich eines zitierten "PUBLIC"-Namens sowie der Indizierung der Tabelle unter Großbuchstaben "PUBLIC", was inkonsistent war.

  Referenzen: #9459

2.0.5.post1

Veröffentlicht: 5. März 2023

orm

• [orm] [bug]

  Konstruktorargumente zu den integrierten Mapping-Sammlungstypen hinzugefügt, darunter KeyFuncDict, attribute_keyed_dict(), column_keyed_dict(), damit diese Dictionary-Typen direkt mit den vorhandenen Daten konstruiert werden können. Dies bietet weitere Kompatibilität mit Tools wie Python-Datenklassen .asdict(), die auf der direkten Verwendung dieser Klassen als normale Dictionary-Klassen beruhen.

  Referenzen: #9418

• [orm] [bug] [regression]

  Mehrere Regressionen aufgrund von #8372 behoben, die attribute_mapped_collection() (jetzt attribute_keyed_dict() genannt) betrafen.

  Erstens war die Sammlung mit "Schlüssel"-Attributen, die keine einfachen zugeordneten Attribute waren, nicht mehr verwendbar; Attribute, die mit Deskriptoren und/oder Assoziationsproxy-Attributen verknüpft waren, wurden korrigiert.

  Zweitens würde ein Ereignis oder eine andere Operation, die den "Schlüssel" zum Befüllen des Wörterbuchs aus einem nicht geladenen zugeordneten Attribut benötigte, ebenfalls unangemessen einen Fehler auslösen, anstatt zu versuchen, das Attribut zu laden, wie es in 1.4 der Fall war. Dies ist ebenfalls behoben.

  In beiden Fällen wurde das Verhalten von #8372 erweitert. #8372 führte einen Fehler ein, der ausgelöst wurde, wenn der abgeleitete Schlüssel, der als zugeordneter Dictionary-Schlüssel verwendet würde, effektiv nicht zugewiesen war. In dieser Änderung wird nur eine Warnung ausgegeben, wenn der effektive Wert des ".key"-Attributs None ist, wo nicht eindeutig bestimmt werden kann, ob dieses None beabsichtigt war oder nicht. None wird in Zukunft nicht mehr als Schlüssel für zugeordnete Sammlungen unterstützt (da es typischerweise NULL bedeutet, was "unbekannt" heißt). Das Setzen von attribute_keyed_dict.ignore_unpopulated_attribute ignoriert nun auch solche None-Schlüssel.

  Referenzen: #9424

• [orm] [bug]

  Identifiziert, dass die Dialekte sqlite und mssql+pyodbc nun mit dem "versioned rows"-Feature des SQLAlchemy ORM kompatibel sind, da SQLAlchemy nun die Zeilenanzahl für eine RETURNING-Anweisung in diesem speziellen Fall durch Zählen der zurückgegebenen Zeilen berechnet, anstatt sich auf cursor.rowcount zu verlassen. Insbesondere der ORM-Anwendungsfall "versioned rows" (dokumentiert unter Konfigurieren eines Version-Counters) sollte nun mit dem SQL Server pyodbc-Dialekt vollständig unterstützt werden.

• [orm] [bug]

  Unterstützung für den Parameter Mapper.polymorphic_load hinzugefügt, um ihn auf jeden Mapper einer Vererbungshierarchie anzuwenden, die mehr als eine Ebene tief ist. Dies ermöglicht das Laden von Spalten für alle Klassen in der Hierarchie, die "selectin" angeben, mit einer einzigen Anweisung, anstatt Elemente auf diesen Zwischenklassen zu ignorieren, die dennoch angeben, dass sie auch an "selectin"-Laden teilnehmen und nicht Teil der untersten SELECT-Anweisung waren.

  Referenzen: #9373

• [orm] [bug]

  Fortsetzung der Korrektur für #8853, wodurch der Mapped-Name vollständig qualifiziert werden kann, unabhängig davon, ob from __annotations__ import future vorhanden war oder nicht. Dieses Problem, das erstmals in 2.0.0b3 behoben wurde, bestätigte, dass dieser Fall über die Testsuite funktionierte. Die Testsuite testete jedoch offenbar nicht das Verhalten für den Namen Mapped, der nicht lokal vorhanden war. Die String-Auflösung wurde aktualisiert, um sicherzustellen, dass das Mapped-Symbol auffindbar ist, so wie es vom ORM für diese Funktionen verwendet wird.

  Referenzen: #8853, #9335

orm declarative

• [bug] [orm declarative]

  Problem behoben, bei dem die neue Funktion mapped_column.use_existing_column nicht funktionierte, wenn die beiden gleichnamigen Spalten unter Attributnamen zugeordnet waren, die sich von einem expliziten Namen für die Spalte selbst unterschieden. Die Attributnamen können nun unterschiedlich benannt sein, wenn dieser Parameter verwendet wird.

  Referenzen: #9332

engine

• [engine] [performance]

  Eine kleine Optimierung der Cython-Implementierung von Result durch Verwendung eines cdef für einen bestimmten int-Wert zur Vermeidung von Python-Overhead. Pull-Request von Matus Valo.

  Referenzen: #9343

• [engine] [bug]

  Fehler behoben, bei dem Row-Objekte aufgrund einer versehentlichen Abhängigkeit von einem instabilen Hashwert nicht zuverlässig über Prozesse hinweg entpickelt werden konnten.

  Referenzen: #9423

sql

• [sql] [bug] [regression]

  Wiederherstellung der Legacy-Funktionen nullslast() und nullsfirst() im Import-Namensraum sqlalchemy. Zuvor waren die neueren Funktionen nulls_last() und nulls_first() verfügbar, aber die Legacy-Funktionen wurden versehentlich entfernt.

  Referenzen: #9390

schema

• [schema]

  Validierung, dass das Argument MetaData.schema von MetaData ein String ist, wenn es angegeben wird.

typing

• [typing] [usecase]

  Der von scoped_session.query_property() zurückgegebene Typ wurde mit einem neuen öffentlichen Typ QueryPropertyDescriptor exportiert.

  Referenzen: #9338

• [typing] [bug]

  Fehler behoben, bei dem die Methode Connection.scalars() nicht als zulässig für eine Liste mit mehreren Parametern typisiert war, was nun bei insertmanyvalues-Operationen unterstützt wird.

• [typing] [bug]

  Verbesserte Typisierung für das an Insert.values() und Update.values() übergebene Mapping, um flexibler bei der Sammlungsart zu sein, indem ein schreibgeschütztes Mapping anstelle eines beschreibbaren Dict angegeben wird, was bei zu eingeschränkter Schlüsselart zu Fehlern geführt hätte.

  Referenzen: #9376

• [typing] [bug]

  Fehlende Init-Überladung für den Numeric-Typ-Objekt hinzugefügt, damit PEP-484-Typprüfer den vollständigen Typ korrekt auflösen können, indem sie vom Parameter Numeric.asdecimal ableiten, ob Decimal- oder float-Objekte dargestellt werden.

  Referenzen: #9391

• [typing] [bug]

  Typisierungsfehler behoben, bei dem Select.from_statement() text()- oder TextualSelect-Objekte nicht als gültigen Typ akzeptierte. Zusätzlich wurde die Methode columns repariert, um einen Rückgabetyp zu haben, der fehlte.

  Referenzen: #9398

• [typing] [bug]

  Typisierungsproblem behoben, bei dem with_polymorphic() den Klassentyp nicht korrekt aufzeichnete.

  Referenzen: #9340

postgresql

• [postgresql] [bug]

  Problem in PostgreSQL ExcludeConstraint behoben, bei der Literalwerte als gebundene Parameter und nicht als direkte Inline-Werte kompiliert wurden, wie es für DDL erforderlich ist.

  Referenzen: #9349

• [postgresql] [bug]

  Problem behoben, bei dem die PostgreSQL ExcludeConstraint-Konstruktion in Operationen wie Table.to_metadata() sowie in einigen Alembic-Szenarien nicht kopierbar war, wenn die Einschränkung Textausdruckselemente enthielt.

  Referenzen: #9401

mysql

• [mysql] [bug] [postgresql]

  Die Unterstützung für Pool-Ping-Listener zur Empfang von Ausnahmeereignissen über das Ereignis DialectEvents.handle_error(), das in 2.0.0b1 für #5648 hinzugefügt wurde, berücksichtigte keine dialektspezifischen Ping-Routinen wie die von MySQL und PostgreSQL. Das Dialekt-Feature wurde überarbeitet, sodass alle Dialekte an der Ereignisbehandlung teilnehmen. Zusätzlich wird ein neues boolesches Element ExceptionContext.is_pre_ping hinzugefügt, das angibt, ob diese Operation während der Vor-Ping-Operation erfolgt.

  Für diese Veröffentlichung können externe Dialekte, die eine benutzerdefinierte Methode Dialect.do_ping() implementieren, sich für das neu verbesserte Verhalten entscheiden, indem sie ihre Methode nicht mehr abfangen oder Ausnahmen auf "is_disconnect" prüfen, sondern stattdessen alle Ausnahmen nach außen weiterleiten. Die Prüfung der Ausnahme auf "is_disconnect" wird nun von einer umschließenden Methode des Standard-Dialekts durchgeführt, die sicherstellt, dass der Ereignishaken für alle Ausnahmeszenarien aufgerufen wird, bevor die Ausnahme als "disconnect"-Ausnahme geprüft wird. Wenn eine vorhandene Methode do_ping() weiterhin Ausnahmen abfängt und "is_disconnect" prüft, wird sie wie bisher funktionieren, aber handle_error-Hooks haben keinen Zugriff auf die Ausnahme, wenn sie nicht nach außen weitergeleitet wird.

  Referenzen: #5648

sqlite

• [sqlite] [bug] [regression]

  Regression für SQLite-Verbindungen behoben, bei der die Verwendung des Parameters deterministic beim Einrichten von Datenbankfunktionen bei älteren SQLite-Versionen (vor Version 3.8.3) fehlschlug. Die Versionsprüflogik wurde verbessert, um diesen Fall zu berücksichtigen.

  Referenzen: #9379

mssql

• [mssql] [bug]

  Problem mit dem neuen Uuid-Datentyp behoben, der verhinderte, dass er mit dem pymssql-Treiber funktionierte. Da pymssql anscheinend wieder gepflegt wird, wurde die Testunterstützung für pymssql wiederhergestellt.

  Referenzen: #9414

• [mssql] [bug]

  Der pymssql-Dialekt wurde angepasst, um RETURNING für INSERT-Anweisungen besser zu nutzen, um die zuletzt eingefügten Primärschlüsselwerte abzurufen, ähnlich wie es derzeit für den mssql+pyodbc-Dialekt geschieht.

misc

• [bug] [ext]

  Problem bei der Automap behoben, bei der das Aufrufen von AutomapBase.prepare() von einer bestimmten zugeordneten Klasse anstelle direkt von AutomapBase nicht die korrekte Basisklasse verwendete, wenn Automap neue Tabellen erkannte, sondern die angegebene Klasse verwendete, was dazu führte, dass Mapper Vererbung konfigurieren wollten. Obwohl man AutomapBase.prepare() ohnehin von der Basis aufrufen sollte, sollte es sich bei Aufruf von einer Unterklasse nicht so stark falsch verhalten.

  Referenzen: #9367

• [bug] [ext] [regression]

  Behobene Regression, verursacht durch Typisierung, die zu sqlalchemy.ext.mutable für #8667 hinzugefügt wurde, wobei sich die Semantik der .pop() Methode änderte und die Methode dadurch nicht mehr funktionierte. Pull Request freundlicherweise von Nils Philippsen.

  Referenzen: #9380

2.0.4

Veröffentlicht: 17. Februar 2023

orm

• [orm] [usecase]

  Um eine Änderung in der Spaltenreihenfolge, die von ORM Declarative in SQLAlchemy 2.0 verwendet wird, zu berücksichtigen, wurde ein neuer Parameter mapped_column.sort_order hinzugefügt. Dieser kann verwendet werden, um die Reihenfolge der Spalten zu steuern, die von der ORM in der Tabelle definiert werden. Dies ist nützlich für gängige Anwendungsfälle wie Mixins mit Primärschlüsselspalten, die zuerst in Tabellen erscheinen sollen. Die Änderungsnotizen unter ORM Declarative wendet Spaltenreihenfolgen anders an; Steuern des Verhaltens mit sort_order veranschaulichen die standardmäßige Änderung im Reihenfolgeverhalten (das Teil aller SQLAlchemy 2.0-Releases ist) sowie die Verwendung von mapped_column.sort_order zur Steuerung der Spaltenreihenfolge bei Verwendung von Mixins und mehreren Klassen (neu in 2.0.4).

  Siehe auch

  ORM Declarative wendet Spaltenreihenfolgen anders an; Steuern des Verhaltens mit sort_order

  Referenzen: #9297

• [orm] [usecase]

  Die Methode Session.refresh() lädt nun sofort ein beziehungsgebundenes Attribut, das explizit im Parameter Session.refresh.attribute_names aufgeführt ist, auch wenn es derzeit mit dem "select"-Loader verknüpft ist, der normalerweise ein "lazy" Loader ist, der während eines Refreshs nicht ausgelöst wird. Die "lazy loader"-Strategie erkennt nun, dass die Operation speziell eine vom Benutzer initiierte Session.refresh()-Operation ist, die dieses Attribut explizit benannt hat, und ruft dann die "immediateload"-Strategie auf, um tatsächlich SQL auszugeben, um das Attribut zu laden. Dies sollte insbesondere für einige asyncio-Situationen hilfreich sein, in denen das Laden eines nicht geladenen, lazy geladenen Attributs erzwungen werden muss, ohne das eigentliche lazy-loading-Attributmuster zu verwenden, das in asyncio nicht unterstützt wird.

  Referenzen: #9298

• [orm] [bug] [regression]

  Behobene Regression, eingeführt in Version 2.0.2 aufgrund von #9217, bei der die Verwendung von DML RETURNING-Anweisungen sowie Select.from_statement()-Konstrukten, wie sie in #9217 "behoben" wurden, in Verbindung mit ORM-gemappten Klassen, die Ausdrücke wie bei column_property() verwendeten, zu einem internen Fehler in Core führen würde, wo versucht wurde, den Ausdruck anhand des Namens abzugleichen. Die Korrektur behebt das Core-Problem und passt auch die Korrektur in #9217 an, um für den DML RETURNING-Anwendungsfall, wo sie unnötigen Overhead verursacht, nicht wirksam zu werden.

  Referenzen: #9273

• [orm] [bug]

  Das interne Modul EvaluatorCompiler wurde als privat für die ORM markiert und in _EvaluatorCompiler umbenannt. Für Benutzer, die sich möglicherweise darauf verlassen haben, ist der Name EvaluatorCompiler noch vorhanden, diese Verwendung wird jedoch nicht unterstützt und wird in einer zukünftigen Version entfernt.

orm declarative

• [usecase] [orm declarative]

  Neuer Parameter dataclasses_callable wurde sowohl zur Klasse MappedAsDataclass als auch zur Methode registry.mapped_as_dataclass() hinzugefügt. Dieser Parameter erlaubt die Verwendung eines alternativen Aufrufs an Python dataclasses.dataclass, um Dataclasses zu erzeugen. Der Anwendungsfall hier ist, stattdessen Pydantic's Dataclass-Funktion einzufügen. Anpassungen wurden an der Mixin-Unterstützung vorgenommen, die für #9179 in Version 2.0.1 hinzugefügt wurde, damit die __annotations__ Sammlung des Mixins umgeschrieben wird, um den Mapped Container nicht zu enthalten, so wie es bei gemappten Klassen geschieht, damit der Pydantic-Dataclass-Konstruktor nicht unbekannten Typen ausgesetzt wird.

  Siehe auch

  Integration mit alternativen Dataclass-Anbietern wie Pydantic

  Referenzen: #9266

sql

• [sql] [bug]

  Behobenes Problem, bei dem Elementtypen eines Tupelwerts fest kodiert waren, um die Typen von einem verglichenen Tupel zu übernehmen, wenn der Vergleich den Operator ColumnOperators.in_() verwendete. Dies war inkonsistent mit der üblichen Art und Weise, wie Typen für einen binären Ausdruck bestimmt werden, nämlich dass zuerst der tatsächliche Elementtyp auf der rechten Seite betrachtet wird, bevor der Typ der linken Seite angewendet wird.

  Referenzen: #9313

• [sql]

  Öffentliche Eigenschaft Table.autoincrement_column hinzugefügt, die die als autoincrement identifizierte Spalte in der Spalte zurückgibt.

  Referenzen: #9277

typing

• [typing] [usecase]

  Verbesserte Typunterstützung für die Hybrid Attributes-Erweiterung, aktualisierte Dokumentation zur Verwendung von ORM Annotated Declarative-Mappings und ein neuer Modifikator namens hybrid_property.inplace. Dieser Modifikator bietet eine Möglichkeit, den Zustand eines hybrid_property **in place** zu ändern, was im Wesentlichen dem entsprach, was sehr frühe Versionen von Hybriden taten, bevor SQLAlchemy Version 1.2.0 #3912 dies zur Entfernung von In-place-Mutationen änderte. Diese In-place-Mutation wird nun auf **Opt-in**-Basis wiederhergestellt, um einem einzelnen Hybrid mehrere Methoden zur Verfügung zu stellen, ohne alle Methoden gleich benennen zu müssen und ohne sorgfältig Methoden mit unterschiedlichen Namen "verketten" zu müssen, um die Komposition beizubehalten. Typing-Tools wie Mypy und Pyright erlauben keine gleichnamigen Methoden in einer Klasse, daher wird mit dieser Änderung eine prägnante Methode zur Einrichtung von Hybriden mit Typunterstützung wiederhergestellt.

  Siehe auch

  Verwendung von inplace zur Erstellung von PEP-484-konformen Hybrid-Eigenschaften

  Referenzen: #9321

oracle

• [oracle] [bug]

  Das Verhalten des Parameters thick_mode für den Dialekt python-oracledb wurde angepasst, um False korrekt als Wert zu akzeptieren. Zuvor zeigte nur None an, dass der Thick-Modus deaktiviert werden sollte.

  Referenzen: #9295

2.0.3

Veröffentlicht: 9. Februar 2023

sql

• [sql] [bug] [regression]

  Behobene kritische Regression in der Formulierung von SQL-Ausdrücken in der Serie 2.0 aufgrund von #7744, die die Unterstützung für SQL-Ausdrücke mit vielen Elementen, die wiederholt denselben Operator verwendeten, verbesserte; die Klammergruppierung ging bei Elementen über die ersten beiden hinaus verloren.

  Referenzen: #9271

typing

• [typing] [bug]

  Workaround für typing.Self entfernt, nun wird PEP 673 für die meisten Methoden verwendet, die Self zurückgeben. Als Konsequenz dieser Änderung wird mypy>=1.0.0 nun benötigt, um SQLAlchemy-Code zu typprüfen. Pull Request freundlicherweise von Yurii Karabas.

  Referenzen: #9254

2.0.2

Veröffentlicht: 6. Februar 2023

orm

• [orm] [usecase]

  Neuer Event-Hook MapperEvents.after_mapper_constructed() hinzugefügt, der einen Event-Hook bereitstellt, der ausgeführt wird, sobald das Mapper-Objekt vollständig konstruiert ist, aber bevor der Aufruf von registry.configure() stattfindet. Dies ermöglicht Code, der zusätzliche Mappings und Tabellenstrukturen basierend auf der anfänglichen Konfiguration eines Mapper erstellt, was sich auch in die Declarative-Konfiguration integriert. Zuvor gab es bei der Verwendung von Declarative, wo das Mapper-Objekt während der Klassenerstellung erstellt wird, keine dokumentierte Möglichkeit, Code zu diesem Zeitpunkt auszuführen. Die Änderung soll benutzerdefinierte Mapping-Schemata wie das Beispiel Versioning with a History Table, das zusätzliche Mapper und Tabellen als Reaktion auf die Erstellung von gemappten Klassen generiert, sofort unterstützen.

  Referenzen: #9220

• [orm] [usecase]

  Die selten verwendete Attribute Mapper.iterate_properties und Methode Mapper.get_property(), die hauptsächlich intern verwendet werden, rufen den registry.configure()-Prozess nicht mehr implizit auf. Öffentlicher Zugriff auf diese Methoden ist extrem selten und der einzige Vorteil der Verfügbarkeit von registry.configure() wäre die Möglichkeit, "backref"-Eigenschaften in diesen Sammlungen zu haben. Um den neuen Event MapperEvents.after_mapper_constructed() zu unterstützen, ist die Iteration und der Zugriff auf die internen MapperProperty-Objekte nun ohne Auslösung einer impliziten Konfiguration des Mappers selbst möglich.

  Der öffentlichere Weg zur Iteration aller Mapper-Attribute, die Sammlung Mapper.attrs und ähnliche, rufen immer noch den registry.configure()-Schritt implizit auf und machen so Backref-Attribute verfügbar.

  In allen Fällen ist registry.configure() immer direkt aufrufbar.

  Referenzen: #9220

• [orm] [bug] [ression]

  Behobenes obskures ORM-Vererbungsproblem, verursacht durch #8705, bei dem in einigen Szenarien von geerbten Maklern, die Gruppen von Spalten aus der lokalen Tabelle und der erbenden Tabelle unter einer column_property() anzeigten, dennoch gewarnt wurde, dass Eigenschaften mit demselben Namen implizit kombiniert werden.

  Referenzen: #9232

• [orm] [bug] [regression]

  Behobene Regression, bei der die Funktion Mapper.version_id_col mit einer regulären Python-seitigen inkrementellen Spalte für SQLite und andere Datenbanken, die "rowcount" nicht mit "RETURNING" unterstützen, fehlschlug, da "RETURNING" für solche Spalten angenommen wurde, obwohl dies nicht der Fall war.

  Referenzen: #9228

• [orm] [bug] [regression]

  Behobene Regression bei der Verwendung von Select.from_statement() in einem ORM-Kontext, bei der die Übereinstimmung von Spalten mit SQL-Labels nur anhand des Namens für ORM-Anweisungen, die nicht vollständig textuell waren, deaktiviert wurde. Dies verhinderte, dass beliebige SQL-Ausdrücke mit Spaltennamen-Labels mit der zu ladenden Entität übereinstimmten, was zuvor in der Serie 1.4 und früheren Serien funktionierte. Das frühere Verhalten wurde wiederhergestellt.

  Referenzen: #9217

orm declarative

• [bug] [orm declarative]

  Behobene Regression, verursacht durch die Korrektur für #9171, die selbst eine Regression behoben hat, bezüglich der Mechanik von __init__() bei Klassen, die von DeclarativeBase erben. Die Änderung bewirkte, dass __init__() auf der vom Benutzer definierten Basis angewendet wurde, wenn keine __init__()-Methode direkt in der Klasse vorhanden war. Dies wurde angepasst, so dass __init__() nur dann angewendet wird, wenn keine andere Klasse in der Hierarchie der vom Benutzer definierten Basis eine __init__()-Methode hat. Dies ermöglicht es benutzerdefinierten Basisklassen, die auf DeclarativeBase basieren, Mixins einzuschließen, die selbst eine benutzerdefinierte __init__()-Methode enthalten.

  Referenzen: #9249

• [bug] [orm declarative]

  Behobenes Problem in ORM Declarative Dataclass-Mappings im Zusammenhang mit der neu hinzugefügten Unterstützung für Mixins in 2.0.1 über #9179, bei der eine Kombination aus der Verwendung von Mixins und ORM-Vererbung in einigen Fällen Felder falsch klassifizierte und Feld-Level-Dataclass-Argumente wie init=False verloren gingen.

  Referenzen: #9226

• [bug] [orm declarative]

  ORM Declarative-Mappings repariert, um die Angabe des Parameters Mapper.primary_key innerhalb von __mapper_args__ bei Verwendung von mapped_column() zu ermöglichen. Obwohl diese Verwendung direkt in der 2.0-Dokumentation steht, akzeptierte Mapper in diesem Kontext die Konstruktion mapped_column() nicht. Diese Funktion funktionierte bereits für die Parameter Mapper.version_id_col und Mapper.polymorphic_on.

  Als Teil dieser Änderung kann das Attribut __mapper_args__ ohne Verwendung von declared_attr() in einer nicht-gemappten Mixin-Klasse angegeben werden, einschließlich eines Eintrags `"primary_key"`, der auf Column- oder mapped_column()-Objekte verweist, die lokal auf dem Mixin vorhanden sind; Declarative übersetzt diese Spalten auch in die richtigen für eine bestimmte gemappte Klasse. Dies funktionierte bereits für die Parameter Mapper.version_id_col und Mapper.polymorphic_on. Zusätzlich können Elemente innerhalb von `"primary_key"` als Zeichenkettennamen vorhandener gemappter Eigenschaften angegeben werden.

  Referenzen: #9240

• [bug] [orm declarative]

  Es wird ein expliziter Fehler ausgelöst, wenn ein Mapping versucht, die Verwendung von MappedAsDataclass mit registry.mapped_as_dataclass() innerhalb derselben Klassenhierarchie zu mischen, da dies zu Problemen führt, wenn die Dataclass-Funktion zur falschen Zeit auf die gemappte Klasse angewendet wird, was zu Fehlern während des Mapping-Prozesses führt.

  Referenzen: #9211

examples

• [examples] [bug]

  Das Beispiel Versioning with a History Table wurde für Version 2.0 überarbeitet und gleichzeitig die allgemeine Funktionsweise dieses Beispiels verbessert, indem neuere APIs verwendet wurden, einschließlich eines neu hinzugefügten Hooks MapperEvents.after_mapper_constructed().

  Referenzen: #9220

sql

• [sql] [usecase]

  Eine vollständige Reihe neuer SQL-Bitwise-Operatoren wurde hinzugefügt, um datenbankseitige Bitwise-Ausdrücke auf geeignete Datenwerte wie Ganzzahlen, Bit-Strings und ähnliche anzuwenden. Pull Request freundlicherweise von Yegor Statkevich.

  Siehe auch

  Bitweise Operatoren

  Referenzen: #8780

asyncio

• [asyncio] [bug]

  Behobene Regression, verursacht durch die Korrektur für #8419, die asyncpg-Verbindungen zurücksetzte (d.h. Transaktion rollback() aufgerufen) und normal an den Pool zurückgab, falls die Verbindung nicht explizit an den Connection Pool zurückgegeben wurde und stattdessen von Python's Garbage Collection abgefangen wurde, was fehlschlägt, wenn der Garbage Collection-Vorgang außerhalb der asyncio-Ereignisschleife aufgerufen wird, was zu einer großen Menge an Stack-Trace-Aktivitäten führt, die in das Logging und die Standardausgabe geschrieben werden.

  Das korrekte Verhalten wird wiederhergestellt, nämlich dass alle asyncio-Verbindungen, die aufgrund der Nicht-Expliziten-Rückgabe an den Connection Pool von der Garbage Collection betroffen sind, vom Pool getrennt und verworfen werden, zusammen mit einer Warnung, anstatt an den Pool zurückgegeben zu werden, da sie nicht zuverlässig zurückgesetzt werden können. Im Falle von asyncpg-Verbindungen wird die asyncpg-spezifische Methode terminate() verwendet, um die Verbindung während dieses Prozesses anmutiger zu beenden, anstatt sie einfach zu verwerfen.

  Diese Änderung beinhaltet eine kleine Verhaltensänderung, von der gehofft wird, dass sie für das Debugging von asyncio-Anwendungen nützlich ist: Die Warnung, die im Falle von unerwartet von der Garbage Collection betroffenen asyncio-Verbindungen ausgegeben wird, wurde etwas aggressiver gemacht, indem sie aus einem try/except-Block in einen finally:-Block verschoben wurde, wo sie bedingungslos ausgegeben wird, unabhängig davon, ob die Trennungs-/Terminierungsoperation erfolgreich war oder nicht. Sie hat auch den Effekt, dass Anwendungen oder Testsuiten, die Python-Warnungen in Ausnahmen umwandeln, dies als vollständige Ausnahmelösung sehen, während es zuvor nicht möglich war, dass diese Warnung tatsächlich als Ausnahme weitergegeben wird. Anwendungen und Testsuiten, die diese Warnung vorübergehend tolerieren müssen, sollten den Python-Warnungsfilter so anpassen, dass diese Warnungen nicht ausgelöst werden.

  Das Verhalten für traditionelle synchrone Verbindungen bleibt unverändert: Garbage collected Verbindungen werden normal an den Pool zurückgegeben, ohne eine Warnung auszugeben. Dies wird wahrscheinlich in einer zukünftigen Hauptversion geändert werden, um zumindest eine ähnliche Warnung auszugeben, wie sie für asyncio-Treiber ausgegeben wird, da es ein Nutzungsfehler ist, wenn gepoolte Verbindungen von der Garbage Collection abgefangen werden, ohne ordnungsgemäß an den Pool zurückgegeben zu werden.

  Referenzen: #9237

mysql

• [mysql] [bug] [regression]

  Behobene Regression, verursacht durch Problem #9058, das die has_table() des MySQL-Dialekts auf die erneute Verwendung von "DESCRIBE" angepasst hat, wobei der spezifische Fehlercode, der von MySQL Version 8 bei Verwendung eines nicht vorhandenen Schemanamens ausgelöst wurde, unerwartet war und nicht als boolesches Ergebnis interpretiert werden konnte.

  Referenzen: #9251

• [mysql] [bug]

  Unterstützung für die neue AS <name> ON DUPLICATE KEY-Syntax von MySQL 8 bei Verwendung von Insert.on_duplicate_key_update() hinzugefügt. Dies ist für neuere Versionen von MySQL 8 erforderlich, da die vorherige Syntax mit VALUES() bei diesen Versionen nun eine Deprecation-Warnung ausgibt. Die Serverversionserkennung wird verwendet, um zu bestimmen, ob die traditionelle MariaDB / MySQL < 8 VALUES()-Syntax verwendet werden soll, im Gegensatz zur neueren MySQL 8-erforderlichen Syntax. Pull Request freundlicherweise von Caspar Wylie.

  Referenzen: #8626

sqlite

• [sqlite] [bug]

  Die Funktion has_table() des SQLite-Dialekts wurde korrigiert, um für Abfragen, die einen nicht-None-Schemanamen für ein nicht existierendes Schema enthalten, korrekt False zurückzugeben; zuvor wurde ein Datenbankfehler ausgelöst.

  Referenzen: #9251

2.0.1

Veröffentlicht: 1. Februar 2023

orm

• [orm] [bug] [regression]

  Behobene Regression, bei der ORM-Modelle, die Joined Table Inheritance mit einem zusammengesetzten Fremdschlüssel verwendeten, einen internen Fehler in der Mapper-Interna erhielten.

  Referenzen: #9164

• [orm] [bug]

  Verbesserte Fehlermeldungen beim Verknüpfen von Strategieoptionen aus einer Basisklasse mit einem anderen Attribut, das von einer abgeleiteten Klasse stammt, bei der of_type() verwendet werden sollte. Zuvor fehlte bei der Verwendung von Load.options() eine informative Meldung, dass of_type() verwendet werden sollte, was nicht der Fall war, wenn die Optionen direkt verknüpft wurden. Die informativen Details werden nun auch dann ausgegeben, wenn Load.options() verwendet wird.

  Referenzen: #9182

orm declarative

• [bug] [orm declarative]

  Unterstützung für PEP 484 NewType wurde zur Verwendung in registry.type_annotation_map sowie in Mapped-Konstrukten hinzugefügt. Diese Typen verhalten sich im Moment genauso wie benutzerdefinierte Unterklassen von Typen; sie müssen explizit in der registry.type_annotation_map erscheinen, um abgebildet zu werden.

  Referenzen: #9175

• [bug] [orm declarative]

  Wenn die Superklasse MappedAsDataclass verwendet wird, werden alle Klassen innerhalb der Hierarchie, die Unterklassen dieser Klasse sind, nun über die Funktion @dataclasses.dataclass ausgeführt, unabhängig davon, ob sie tatsächlich gemappt werden oder nicht. Dadurch werden Nicht-ORM-Felder, die auf nicht gemappten Klassen innerhalb der Hierarchie deklariert sind, verwendet, wenn gemappte Unterklassen in Dataclasses umgewandelt werden. Dieses Verhalten gilt sowohl für Zwischenklassen, die mit __abstract__ = True gemappt wurden, als auch für die benutzerdefinierte deklarative Basis selbst, vorausgesetzt, MappedAsDataclass ist als Oberklasse für diese Klassen vorhanden.

  Dies ermöglicht die Verwendung von nicht gemappten Attributen wie InitVar Deklarationen auf Superklassen, ohne den @dataclasses.dataclass Dekorator explizit auf jeder nicht gemappten Klasse ausführen zu müssen. Das neue Verhalten wird als korrekt angesehen, da dies dem entspricht, was die Implementierung von PEP 681 erwartet, wenn eine Superklasse zur Angabe des Dataclass-Verhaltens verwendet wird.

  Referenzen: #9179

• [bug] [orm declarative]

  Unterstützung für PEP 586 Literal[] wurde zur Verwendung in der registry.type_annotation_map sowie innerhalb von Mapped Konstrukten hinzugefügt. Um benutzerdefinierte Typen wie diese zu verwenden, müssen sie explizit in der registry.type_annotation_map aufgeführt werden, um gemappt zu werden. Pull-Request von Frederik Aalund.

  Als Teil dieser Änderung wurde die Unterstützung für Enum in der registry.type_annotation_map erweitert, um neben enum.Enum Datentypen auch Literal[] Typen, die aus Zeichenkettenwerten bestehen, zu unterstützen. Wenn ein Literal[] Datentyp innerhalb von Mapped[] verwendet wird, der nicht in der registry.type_annotation_map mit einem bestimmten Datentyp verknüpft ist, wird standardmäßig ein Enum verwendet.

  Siehe auch

  Verwendung von Python Enum oder pep-586 Literal-Typen in der Typ-Map

  Referenzen: #9187

• [bug] [orm declarative]

  Behebt ein Problem bei der Verwendung von Enum in der registry.type_annotation_map, bei dem der Parameter Enum.native_enum nicht korrekt an den gemappten Spaltendatentyp kopiert wurde, falls er auf False gesetzt war, wie in der Dokumentation angegeben.

  Referenzen: #9200

• [bug] [orm declarative] [regression]

  Behebt eine Regression in der Klasse DeclarativeBase, bei der der Standardkonstruktor des Registries nicht auf die Basis selbst angewendet wurde, was sich von der Funktionsweise des vorherigen declarative_base() Konstrukts unterscheidet. Dies verhinderte, dass eine gemappte Klasse mit eigener __init__() Methode super().__init__() aufrufen konnte, um auf den Standardkonstruktor der Registry zuzugreifen und Attribute automatisch zu befüllen. Stattdessen wurde object.__init__() aufgerufen, was bei beliebigen Argumenten zu einem TypeError führte.

  Referenzen: #9171

• [bug] [orm declarative]

  Die Regeln zur Interpretation von PEP 593 Annotated Typen bei Verwendung mit Annotated Declarative Mapping wurden verbessert. Der innere Typ wird in allen Fällen auf "Optional" geprüft und dies zur Kriteriendefinition hinzugefügt, ob die Spalte als "nullable" gesetzt wird oder nicht. Wenn der Typ innerhalb des Annotated Containers optional ist (oder mit None unioned), wird die Spalte als nullable betrachtet, sofern keine expliziten mapped_column.nullable Parameter sie überschreiben.

  Referenzen: #9177

sql

• [sql] [bug]

  Die Korrektur für #7664, veröffentlicht in Version 2.0.0, wurde korrigiert, um auch DropSchema einzuschließen, das bei dieser Korrektur versehentlich übersehen wurde, und ermöglicht die Stringifizierung ohne Dialekt. Die Korrekturen für beide Konstrukte wurden in die 1.4er Serie ab 1.4.47 zurückportiert.

  Referenzen: #7664

• [sql] [bug] [regression]

  Behebt eine Regression in der Implementierung des neuen „insertmanyvalues“-Features, bei dem ein interner TypeError in Konfigurationen auftrat, in denen ein insert() über eine CTE innerhalb eines anderen insert() referenziert wurde. Zusätzliche Korrekturen wurden für diesen Anwendungsfall für positionelle Dialekte wie asyncpg bei der Verwendung von „insertmanyvalues“ vorgenommen.

  Referenzen: #9173

typing

• [typing] [bug]

  Die Typisierung für Select.with_for_update.of wurde erweitert, um auch Tabellen- und gemappte Klassenargumente zu akzeptieren, wie es für den MySQL-Dialekt verfügbar zu sein scheint.

  Referenzen: #9174

• [typing] [bug]

  Die Typisierung für limit/offset-Methoden, einschließlich Select.limit(), Select.offset(), Query.limit(), Query.offset() wurde korrigiert, um None zuzulassen, was die dokumentierte API ist, um das aktuelle Limit/Offset zu "brechen".

  Referenzen: #9183

• [typing] [bug]

  Behebt ein Typisierungsproblem, bei dem mapped_column() Objekte, die als Mapped typisiert wurden, nicht in Schema-Constraints wie ForeignKey, UniqueConstraint oder Index akzeptiert wurden.

  Referenzen: #9170

• [typing] [bug]

  Die Typisierung für ColumnElement.cast() wurde korrigiert, um sowohl Type[TypeEngine[T]] als auch TypeEngine[T] zu akzeptieren; zuvor wurde nur TypeEngine[T] akzeptiert. Pull-Request von Yurii Karabas.

  Referenzen: #9156

2.0.0

Veröffentlicht: 26. Januar 2023

orm

• [orm] [bug]

  Die Benachrichtigung von Warnungen, die im Konfigurations-Mapper- oder Flush-Prozess ausgegeben werden und oft als Teil einer anderen Operation aufgerufen werden, wurde verbessert, um zusätzliche Kontexte zur Meldung hinzuzufügen, die eine dieser Operationen als Quelle der Warnung angibt, auch bei Operationen, die nicht offensichtlich damit zusammenhängen.

  Referenzen: #7305

orm extensions

• [feature] [orm extensions]

  Neue Option zur horizontalen Sharding-API set_shard_id hinzugefügt, die den effektiven Shard-Identifier für Abfragen festlegt, sowohl für die primäre Abfrage als auch für alle sekundären Lader, einschließlich Relationship-Eager-Lader sowie Relationship- und Column-Lazy-Lader.

  Referenzen: #7226

• [usecase] [orm extensions]

  Neues Feature für AutomapBase für das automatische Laden von Klassen über mehrere Schemata hinweg, die überlappende Namen haben könnten. Dies wird durch einen Parameter AutomapBase.prepare.modulename_for_table ermöglicht, der die Anpassung des __module__ Attributs neu generierter Klassen erlaubt, sowie eine neue Sammlung AutomapBase.by_module, die einen punktgetrennten Namensraum von Modulnamen speichert, die mit Klassen basierend auf dem __module__ Attribut verknüpft sind.

  Zusätzlich kann die Methode AutomapBase.prepare() nun beliebig oft aufgerufen werden, mit oder ohne Aktivierung der Reflexion; nur neu hinzugefügte Tabellen, die noch nicht gemappt wurden, werden bei jedem Aufruf verarbeitet. Zuvor musste die Methode MetaData.reflect() jedes Mal explizit aufgerufen werden.

  Siehe auch

  Generieren von Mappings aus mehreren Schemata - illustriert die Verwendung beider Techniken gleichzeitig.

  Referenzen: #5145

sql

• [sql] [bug]

  Stringifizierung für den CreateSchema DDL-Konstrukt wurde behoben, der mit einem AttributeError abstürzte, wenn er ohne Dialekt stringifiziert wurde. Update: Beachten Sie, dass diese Korrektur DropSchema nicht berücksichtigte; eine Nachkorrektur in Version 2.0.1 behebt diesen Fall. Die Korrektur für beide Elemente wird nach 1.4.47 zurückportiert.

  Referenzen: #7664

typing

• [typing] [bug]

  Typisierung für die integrierten generischen Funktionen im func Namensraum hinzugefügt, die eine bestimmte Menge von Argumenten akzeptieren und einen bestimmten Typ zurückgeben, z. B. für count, current_timestamp usw.

  Referenzen: #9129

• [typing] [bug]

  Der für "Lambda-Statements" übergebene Typ wurde korrigiert, sodass eine einfache Lambda von mypy, pyright usw. ohne Fehler bezüglich der Argumenttypen akzeptiert wird. Darüber hinaus wurde die Typisierung für weitere Teile der öffentlichen API für Lambda-Statements implementiert und sichergestellt, dass StatementLambdaElement Teil der Executable Hierarchie ist, sodass sie als von Connection.execute() akzeptiert typisiert wird.

  Referenzen: #9120

• [typing] [bug]

  Die Methoden ColumnOperators.in_() und ColumnOperators.not_in() sind so typisiert, dass sie Iterable[Any] anstelle von Sequence[Any] akzeptieren, um mehr Flexibilität bei den Argumenttypen zu ermöglichen.

  Referenzen: #9122

• [typing] [bug]

  Die Funktionen or_() und and_() erfordern aus Typsicht, dass das erste Argument vorhanden ist. Diese Funktionen akzeptieren jedoch immer noch null Argumente, was zur Laufzeit eine Deprecation-Warnung ausgibt. Die Typisierung wurde auch erweitert, um das Senden des festen Literals False für or_() und True für and_() als einziges erstes Argument zu unterstützen. Die Dokumentation empfiehlt jedoch jetzt, in diesen Fällen die Konstrukte false() und true() als explizitere Methode zu verwenden.

  Referenzen: #9123

• [typing] [bug]

  Behebt ein Typisierungsproblem, bei dem das Iterieren über ein Query Objekt nicht korrekt typisiert war.

  Referenzen: #9125

• [typing] [bug]

  Behebt ein Typisierungsproblem, bei dem der Objekttyp bei Verwendung von Result als Kontextmanager nicht erhalten blieb, sodass in allen Fällen Result anstelle des spezifischen Result Subtyps angezeigt wurde. Pull-Request von Martin Baláž.

  Referenzen: #9136

• [typing] [bug]

  Behebt ein Problem, bei dem die Verwendung von relationship.remote_side und ähnlichen Parametern, bei denen ein annotiertes deklaratives Objekt, das als Mapped typisiert wurde, vom Typenprüfer nicht akzeptiert wurde.

  Referenzen: #9150

• [typing] [bug]

  Typisierung für ältere Operatoren wie isnot(), notin_() usw. hinzugefügt, die zuvor auf neuere Operatoren verwiesen, aber selbst nicht typisiert waren.

  Referenzen: #9148

postgresql

• [postgresql] [bug]

  Dem asyncpg-Dialekt wurde die Unterstützung hinzugefügt, um den cursor.rowcount Wert für SELECT-Statements zurückzugeben, falls verfügbar. Obwohl dies kein typischer Anwendungsfall für cursor.rowcount ist, stellen die anderen PostgreSQL-Dialekte diesen Wert generell zur Verfügung. Pull-Request von Michael Gorven.

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

  Referenzen: #9048

mysql

• [mysql] [usecase]

  Die MySQL-Index-Reflexion wurde um Unterstützung für die korrekte Reflexion des mysql_length Wörterbuchs erweitert, das zuvor ignoriert wurde.

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

  Referenzen: #9047

mssql

• [mssql] [bug] [regression]

  Die neu hinzugefügte Kommentar-Reflexions- und Rendering-Funktion des MSSQL-Dialekts, die in #7844 hinzugefügt wurde, wird nun standardmäßig deaktiviert, wenn nicht festgestellt werden kann, dass ein nicht unterstütztes Backend wie Azure Synapse verwendet wird; dieses Backend unterstützt keine Tabellen- und Spaltenkommentare und auch nicht die SQL Server-Routinen zur Erstellung und Reflexion derselben. Ein neuer Parameter supports_comments wurde dem Dialekt hinzugefügt, der standardmäßig auf None gesetzt ist, was bedeutet, dass die Kommentarunterstützung automatisch erkannt wird. Wenn er auf True oder False gesetzt wird, wird die Kommentarunterstützung entweder bedingungslos aktiviert oder deaktiviert.

  Siehe auch

  Unterstützung für DDL-Kommentare

  Referenzen: #9142

2.0.0rc3

Veröffentlicht: 18. Januar 2023

orm

• [orm] [feature]

  Ein neuer Parameter Mapper.polymorphic_abstract wurde zur Mapper hinzugefügt. Der Zweck dieser Direktive ist, dass die ORM die Klasse nicht direkt instanziiert oder lädt, sondern nur ihre Unterklassen. Die eigentliche Auswirkung ist, dass der Mapper die direkte Instanziierung von Objekten der Klasse verhindert und erwartet, dass die Klasse keine eigenständige polymorphe Identität konfiguriert hat.

  In der Praxis kann die Klasse, die mit Mapper.polymorphic_abstract gemappt ist, als Ziel einer relationship() sowie in Abfragen verwendet werden; Unterklassen müssen natürlich polymorphe Identitäten in ihren Mappings enthalten.

  Der neue Parameter wird automatisch auf Klassen angewendet, die von der Klasse AbstractConcreteBase abstammen, da diese Klasse nicht zur Instanziierung vorgesehen ist.

  Siehe auch

  Aufbau tieferer Hierarchien mit polymorphic_abstract

  Referenzen: #9060

• [orm] [bug]

  Behobenes Problem, bei dem die Verwendung eines pep-593 Annotated-Typs in der registry.type_annotation_map, die selbst einen generischen einfachen Container oder collections.abc-Typ (z. B. list, dict, collections.abc.Sequence usw.) als Zieltyp enthielt, zu einem internen Fehler führte, wenn die ORM die Annotated-Instanz interpretierte.

  Referenzen: #9099

• [orm] [bug]

  Eine Fehlermeldung wurde hinzugefügt, wenn ein relationship() gegen einen abstrakten Containertyp wie Mapped[Sequence[B]] zugeordnet wird, ohne den Parameter relationship.container_class anzugeben, der erforderlich ist, wenn der Typ abstrakt ist. Zuvor wurde versucht, den abstrakten Container in einem späteren Schritt zu instanziieren und schlug fehl.

  Referenzen: #9100

sql

• [sql] [bug]

  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 die Parameter dargestellt wurden, stillschweigend nicht berücksichtigt wurde, indem der Ausdruck durch einen neuen Parameter mit demselben Namen ersetzt und alle anderen Elemente des SQL-Ausdrucks, wie 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 es würde auftreten, wenn die Anweisung mit einer Session oder einer Connection aufgerufen würde.

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

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

  Referenzen: #9075

typing

• [typing] [bug]

  Korrekturen an den Annotationen innerhalb der Erweiterung sqlalchemy.ext.hybrid für eine effektivere Typisierung benutzerdefinierter Methoden. Die Typisierung verwendet jetzt PEP 612-Features, die jetzt von neueren Versionen von Mypy unterstützt werden, um Argumentsignaturen für hybrid_method beizubehalten. Rückgabewerte für Hybridmethoden werden als SQL-Ausdrücke in Kontexten wie Select.where() akzeptiert und unterstützen weiterhin SQL-Methoden.

  Referenzen: #9096

mypy

• [mypy] [bug]

  Anpassungen am mypy-Plugin, um einige potenzielle Änderungen im Zusammenhang mit Issue #236 sqlalchemy2-stubs bei der Verwendung von SQLAlchemy 1.4 zu berücksichtigen. Diese Änderungen werden innerhalb von SQLAlchemy 2.0 synchron gehalten. Die Änderungen sind außerdem abwärtskompatibel mit älteren Versionen von sqlalchemy2-stubs.

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

• [mypy] [bug]

  Abgestürztes Verhalten im mypy-Plugin behoben, das sowohl bei 1.4 als auch bei 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 jetzt ignoriert; bei Verwendung des Plugins muss der Dekoratorkausdruck zwei Komponenten haben (d. h. @reg.mapped).

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

  Referenzen: #9102

postgresql

• [postgresql] [bug]

  Regression behoben, bei der psycopg3 eine API-Aufrufoperation ab Version 3.1.8 so geändert hat, dass ein bestimmter Objekttyp erwartet wurde, der zuvor nicht erzwungen wurde, was die Konnektivität für den psycopg3-Dialekt unterbrach.

  Referenzen: #9106

oracle

• [oracle] [usecase]

  Unterstützung für den Oracle SQL-Typ TIMESTAMP WITH LOCAL TIME ZONE hinzugefügt, unter Verwendung eines neu hinzugefügten Oracle-spezifischen TIMESTAMP-Datentyps.

  Referenzen: #9086

2.0.0rc2

Veröffentlicht: 9. Januar 2023

orm

• [orm] [bug]

  Behobenes Problem, bei dem eine übermäßig restriktive ORM-Mapping-Regel in 2.0 hinzugefügt wurde, die Zuordnungen zu TableClause-Objekten, wie sie im Wiki-Rezept für Ansichten verwendet werden, verhinderte.

  Referenzen: #9071

typing

• [typing] [bug]

  Das Argument field_descriptors der Data Class Transforms wurde in der akzeptierten Version von PEP 681 in field_specifiers umbenannt.

  Referenzen: #9067

postgresql

• [postgresql] [json]

  Fehlende JSONB-Operationen implementiert

  • @@ unter Verwendung von Comparator.path_match()

  • @? unter Verwendung von Comparator.path_exists()

  • #- unter Verwendung von Comparator.delete_path()

  Pull-Request von Guilherme Martins Crocetti.

  Referenzen: #7147

mysql

• [mysql] [bug]

  Das Verhalten von Inspector.has_table() wurde wiederhergestellt, um temporäre Tabellen für MySQL / MariaDB zu melden. Dies ist derzeit das Verhalten für alle anderen enthaltenen Dialekte, wurde jedoch für MySQL in 1.4 entfernt, da der DESCRIBE-Befehl nicht mehr verwendet wurde; es gab keine dokumentierte Unterstützung für temporäre Tabellen, die von der Methode Inspector.has_table() in dieser oder einer früheren Version gemeldet wurden, sodass das vorherige Verhalten undefiniert war.

  Da SQLAlchemy 2.0 die formale Unterstützung für den Status temporärer Tabellen über Inspector.has_table() hinzugefügt hat, wurde der MySQL / MariaDB-Dialekt so zurückgesetzt, dass er die „DESCRIBE“-Anweisung verwendet, wie dies in der SQLAlchemy 1.3-Serie und früher der Fall war, und die Testunterstützung wurde hinzugefügt, um MySQL / MariaDB für dieses Verhalten einzuschließen. Die früheren Probleme mit ROLLBACK, die 1.4 verbessern sollte, gelten in SQLAlchemy 2.0 nicht mehr aufgrund von Vereinfachungen, wie Connection Transaktionen handhabt.

  DESCRIBE ist notwendig, da MariaDB insbesondere keine konsistent verfügbare öffentliche Informationsschemata hat, um temporäre Tabellen anders als DESCRIBE/SHOW COLUMNS zu melden, die darauf angewiesen sind, einen Fehler auszulösen, um keine Ergebnisse zu melden.

  Referenzen: #9058

oracle

• [oracle] [bug]

  Unterstützter Anwendungsfall für Fremdschlüsselbeschränkungen, bei denen die lokale Spalte als „unsichtbar“ gekennzeichnet ist. Die normalerweise generierten Fehler, wenn eine ForeignKeyConstraint erstellt wird, die auf die Zielspalte prüft, werden beim Reflektieren deaktiviert, und die Beschränkung wird mit einer Warnung übersprungen, so wie es bereits für einen Index mit einem ähnlichen Problem geschieht.

  Referenzen: #9059

2.0.0rc1

Veröffentlicht: 28. Dezember 2022

general

• [general] [bug]

  Regression behoben, bei der das Basis-Kompatibilitätsmodul platform.architecture() aufrief, um einige Systeminformationen zu erkennen, was zu einem übermäßigen Systemaufruf gegen den systemweiten file-Aufruf führte, der unter bestimmten Umständen, einschließlich einiger sicherer Umgebungskonfigurationen, nicht verfügbar ist.

  Diese Änderung wird auch zurückportiert nach: 1.4.46

  Referenzen: #8995

orm

• [orm] [feature]

  Ein neuer Standardwert für den Parameter Mapper.eager_defaults, „auto“, wurde hinzugefügt. Dieser ruft automatisch Tabellendatenbank-Standardwerte während eines Unit-of-Work-Flushs ab, wenn der Dialekt RETURNING für das ausgeführte INSERT unterstützt, sowie insertmanyvalues verfügbar ist. Eager-Abrufe für serverseitige UPDATE-Standardwerte, die sehr ungewöhnlich sind, finden nur statt, wenn Mapper.eager_defaults auf True gesetzt ist, da es keine Batch-RETURNING-Form für UPDATE-Anweisungen gibt.

  Referenzen: #8889

• [orm] [usecase]

  Anpassungen an der Session in Bezug auf Erweiterbarkeit sowie Aktualisierungen der ShardedSession-Erweiterung

  • Session.get() akzeptiert jetzt Session.get.bind_arguments, was insbesondere bei der Verwendung der horizontalen Sharding-Erweiterung nützlich sein kann.

  • Session.get_bind() akzeptiert beliebige Schlüsselwortargumente, was bei der Entwicklung von Code hilft, der eine Session-Klasse verwendet, die diese Methode mit zusätzlichen Argumenten überschreibt.

  • Eine neue ORM-Ausführungsoption identity_token wurde hinzugefügt, die verwendet werden kann, um den „Identitätstoken“ direkt zu beeinflussen, der neu geladenen ORM-Objekten zugeordnet wird. Dieser Token ist die Methode, mit der Sharding-Ansätze (insbesondere die ShardedSession, kann aber auch in anderen Fällen verwendet werden) Objektidentitäten über verschiedene „Shards“ hinweg trennen.

    Siehe auch

    Identitätstoken

  • Der Ereignishaken SessionEvents.do_orm_execute() kann jetzt verwendet werden, um alle ORM-bezogenen Optionen zu beeinflussen, einschließlich autoflush, populate_existing und yield_per; diese Optionen werden nach dem Aufrufen der Ereignishaken erneut verarbeitet, bevor sie ausgeführt werden. Zuvor wären Optionen wie autoflush zu diesem Zeitpunkt bereits ausgewertet worden. Die neue Option identity_token wird auch in diesem Modus unterstützt und wird jetzt von der horizontalen Sharding-Erweiterung verwendet.

  • Die Klasse ShardedSession ersetzt den Hook ShardedSession.id_chooser durch einen neuen Hook ShardedSession.identity_chooser, der nicht mehr auf dem Legacy- Query-Objekt basiert. ShardedSession.id_chooser wird weiterhin anstelle von ShardedSession.identity_chooser mit einer Verwarnung akzeptiert.

  Referenzen: #7837

• [orm] [usecase]

  Das Verhalten des „Einbindens einer externen Transaktion in eine Session“ wurde überarbeitet und verbessert, wodurch eine explizite Kontrolle darüber ermöglicht wird, wie die Session eine eingehende Connection, die bereits eine Transaktion und möglicherweise einen Savepoint hat, aufnimmt. Der neue Parameter Session.join_transaction_mode enthält eine Reihe von Optionswerten, die die bestehende Transaktion auf verschiedene Weise aufnehmen können, insbesondere ermöglicht dies einer Session, in einem vollständig transaktionalen Stil ausschließlich mit Savepoints zu arbeiten, während die extern initiierte Transaktion unter allen Umständen nicht committed und aktiv bleibt, was es Testsuiten ermöglicht, alle innerhalb von Tests durchgeführten Änderungen zurückzurollen.

  Zusätzlich wurde die Methode Session.close() überarbeitet, um noch vorhandene Savepoints vollständig zu schließen, was auch dem Rezept der „externen Transaktion“ ermöglicht, ohne Warnungen fortzufahren, wenn die Session ihre eigenen SAVEPOINT-Transaktionen nicht explizit beendet hat.

  Siehe auch

  Neue Transaktionseinbindungsmodi für Session

  Referenzen: #9015

• [orm] [usecase]

  Die Anforderung, dass das Attribut __allow_unmapped__ auf einer Deklarativen Dataclass Mapped-Klasse verwendet werden muss, wenn Nicht-Mapped[]-Annotationen erkannt werden, wurde entfernt; zuvor wurde eine Fehlermeldung ausgegeben, die für Legacy-ORM-typisierte Zuordnungen bestimmt war und zudem keine korrekten Muster speziell für Dataclasses erwähnte. Diese Fehlermeldung wird jetzt nicht mehr ausgegeben, wenn registry.mapped_as_dataclass() oder MappedAsDataclass verwendet wird.

  Siehe auch

  Verwendung von Nicht-Mapped Dataclass Feldern

  Referenzen: #8973

• [orm] [bug]

  Problem in der internen SQL-Traversierung für DML-Anweisungen wie Update und Delete behoben, die unter anderem zu einem spezifischen Problem mit der Verwendung von Lambda-Anweisungen mit der ORM-Update/Delete-Funktion führte.

  Diese Änderung wird auch zurückportiert nach: 1.4.46

  Referenzen: #9033

• [orm] [bug]

  Fehler behoben, bei dem Session.merge() die aktuellen geladenen Inhalte von Beziehungsattributen, die mit dem Parameter relationship.viewonly angegeben waren, nicht beibehielt, wodurch Strategien, die Session.merge() zum Abrufen vollständig geladener Objekte aus Caches und ähnlichen Techniken verwendeten, vereitelt wurden. In einer verwandten Änderung wurde ein Problem behoben, bei dem ein Objekt, das eine geladene Beziehung enthielt, die aber dennoch als lazy='raise' auf dem Mapping konfiguriert war, bei der Übergabe an Session.merge() fehlschlug; Prüfungen auf „raise“ werden jetzt während des Merge-Vorgangs ausgesetzt, vorausgesetzt, der Parameter Session.merge.load bleibt bei seinem Standardwert von True.

  Insgesamt ist dies eine Verhaltensanpassung an eine Änderung, die in der 1.4-Serie ab #4994 eingeführt wurde, die „merge“ aus den standardmäßig angewendeten Kaskaden für „viewonly“-Beziehungen entfernte. Da „viewonly“-Beziehungen unter keinen Umständen persistent gemacht werden, hat die Zulassung, dass ihre Inhalte während des „merge“ übertragen werden, keine Auswirkungen auf das Persistenzverhalten des Zielobjekts. Dies ermöglicht es Session.merge(), einen seiner Anwendungsfälle korrekt zu erfüllen, nämlich das Hinzufügen von Objekten zu einer Session, die woanders geladen wurden, oft zum Zweck der Wiederherstellung aus einem Cache.

  Diese Änderung wird auch zurückportiert nach: 1.4.45

  Referenzen: #8862

• [orm] [bug]

  Probleme in with_expression() behoben, bei denen Ausdrücke, die aus Spalten bestanden, die aus dem umschließenden SELECT referenziert wurden, in einigen Kontexten keinen korrekten SQL-Code renderten, wenn der Ausdruck einen Labelnamen hatte, der mit dem Attribut übereinstimmte, das query_expression() verwendete, selbst wenn query_expression() keinen Standardausdruck hatte. Vorläufig wird, wenn der query_expression() einen Standardausdruck hat, dieser Labelname für diesen Standard verwendet, und ein zusätzliches Label mit demselben Namen wird weiterhin ignoriert. Insgesamt ist dieser Fall ziemlich schwierig, sodass weitere Anpassungen erforderlich sein könnten.

  Diese Änderung wird auch zurückportiert nach: 1.4.45

  Referenzen: #8881

• [orm] [bug]

  Es wird eine Warnung ausgegeben, wenn ein in relationship() verwendeter Backref-Name ein Attribut auf der Zielklasse benennt, das bereits eine Methode oder ein Attribut dieses Namens zugewiesen hat, da die Backref-Deklaration dieses Attribut ersetzt.

  Referenzen: #4629

• [orm] [bug]

  Eine Reihe von Änderungen und Verbesserungen in Bezug auf Session.refresh(). Die Gesamtänderung besteht darin, dass Primärschlüsselattribute für ein Objekt nun bedingungslos in eine Refresh-Operation einbezogen werden, wenn beziehungsgebundene Attribute aktualisiert werden sollen, auch wenn sie nicht abgelaufen sind und auch wenn sie nicht im Refresh angegeben wurden.

  • Verbessertes Session.refresh(), so dass, wenn autoflush aktiviert ist (wie es standardmäßig für Session gilt), der autoflush früher im Refresh-Prozess stattfindet, sodass ausstehende Primärschlüsseländerungen angewendet werden, ohne dass Fehler ausgelöst werden. Zuvor fand dieser Autoflush zu spät im Prozess statt, und die SELECT-Anweisung verwendete nicht den korrekten Schlüssel, um die Zeile zu lokalisieren, und ein InvalidRequestError wurde ausgelöst.

  • Wenn die oben genannte Bedingung vorliegt, d.h. es gibt un-geflushte Primärschlüsseländerungen am Objekt, aber autoflush ist nicht aktiviert, verbietet die Methode refresh() nun explizit die Fortsetzung der Operation und es wird ein informatives InvalidRequestError ausgelöst, das fordert, dass die ausstehenden Primärschlüsseländerungen zuerst geflusht werden. Zuvor war dieser Anwendungsfall einfach kaputt und es wurde ohnehin ein InvalidRequestError ausgelöst. Diese Einschränkung dient dazu, dass die Primärschlüsselattribute sicher aktualisiert werden können, was für den Fall, dass das Objekt mit beziehungsgebundenen sekundären Eagerloadern aktualisiert werden kann, notwendig ist. Diese Regel gilt in allen Fällen, um die API-Verhalten konsistent zu halten, unabhängig davon, ob die PK-Spalten tatsächlich im Refresh benötigt werden oder nicht, da es ohnehin ungewöhnlich ist, einige Attribute eines Objekts zu aktualisieren, während andere Attribute „ausstehend“ bleiben.

  • Die Methode Session.refresh() wurde so erweitert, dass Attribute, die relationship()-gebunden und mit einem Eagerloader verknüpft sind, entweder zum Zeitpunkt des Mappings oder über zuletzt verwendete Loader-Optionen, in allen Fällen aktualisiert werden, auch wenn eine Liste von Attributen übergeben wird, die keine Spalten in der Elterntabelle enthält. Dies baut auf der Funktion auf, die zuerst für Nicht-Spalten-Attribute im Rahmen von #1763 (behoben in 1.4) implementiert wurde und die es Beziehungs-gebundenen Attributen mit Eagerloading ermöglichte, an der Session.refresh()-Operation teilzunehmen. Wenn die Refresh-Operation keine Spalten der Elterntabelle zum Aktualisieren angibt, werden die Primärschlüsselspalten trotzdem in die Refresh-Operation einbezogen, was den Ladevorgang in die sekundären Beziehungsloader fortsetzen lässt, wie es normalerweise der Fall ist. Zuvor würde für diesen Fall ein InvalidRequestError ausgelöst (#8703)

  • Problem behoben, bei dem ein unnötiger zusätzlicher SELECT ausgelöst wurde, wenn Session.refresh() mit einer Kombination aus abgelaufenen Attributen sowie einem Eagerloader wie selectinload(), das eine „sekundäre“ Abfrage auslöst, aufgerufen wurde, wenn die Primärschlüsselattribute ebenfalls im abgelaufenen Zustand waren. Da die Primärschlüsselattribute nun automatisch in den Refresh einbezogen werden, gibt es keinen zusätzlichen Ladevorgang für diese Attribute, wenn ein Beziehungsloader sie auswählt (#8997)

  • Regression behoben, die durch #8126 (veröffentlicht in 2.0.0b1) verursacht wurde, bei der die Methode Session.refresh() mit einem AttributeError fehlschlug, wenn sowohl ein abgelaufener Spaltenname als auch der Name eines beziehungsgebundenen Attributs übergeben wurden, das mit einem „sekundären“ Eagerloader wie dem selectinload() Eagerloader verknüpft war (#8996)

  Referenzen: #8703, #8996, #8997

• [orm] [bug]

  Verbesserte eine Korrektur, die erstmals in Version 1.4 für #8456 vorgenommen wurde und die Verwendung interner „polymorpher Adapter“ zurückgeschraubt hat, die zur Darstellung von ORM-Abfragen verwendet werden, wenn der Parameter Mapper.with_polymorphic verwendet wird. Diese Adapter, die sehr komplex und fehleranfällig sind, werden jetzt nur noch in den Fällen verwendet, in denen eine explizite, vom Benutzer bereitgestellte Unterabfrage für Mapper.with_polymorphic verwendet wird. Dies umfasst nur die Verwendung von konkreten Vererbungszuordnungen, die die Hilfsfunktion polymorphic_union() verwenden, sowie den Legacy-Fall der Verwendung einer alias-unterstützten Unterabfrage für zugeordnete Vererbungszuordnungen, was bei moderner Verwendung nicht mehr erforderlich ist.

  Für den häufigsten Fall von zugeordneten Vererbungszuordnungen, die das integrierte polymorphe Ladeschema verwenden, einschließlich derjenigen, die den Parameter Mapper.polymorphic_load auf inline gesetzt verwenden, werden polymorphe Adapter jetzt nicht mehr verwendet. Dies hat sowohl positive Auswirkungen auf die Leistung bei der Konstruktion von Abfragen als auch eine erhebliche Vereinfachung des internen Abfrage-Rendering-Prozesses.

  Das spezifische Problem, das behoben werden sollte, war die Ermöglichung, dass eine column_property() auf Klassen mit zugeordneter Vererbung innerhalb einer skalaren Unterabfrage verweist, was jetzt so intuitiv wie möglich funktioniert.

  Referenzen: #8168

engine

• [engine] [bug]

  Behobene eine seit langem bestehende Race Condition im Verbindungspool, die unter Eventlet/Gevent Monkeypatching-Schemata in Verbindung mit der Verwendung von Eventlet/Gevent Timeout-Bedingungen auftreten konnte, bei der ein durch Timeout unterbrochener Checkout aus einem Verbindungspool den fehlerhaften Zustand nicht aufräumen konnte, was dazu führte, dass der zugrunde liegende Verbindungsdatensatz und manchmal die Datenbankverbindung selbst „lecken“ und den Pool in einem ungültigen Zustand mit unerreichbaren Einträgen hinterließen. Dieses Problem wurde erstmals in SQLAlchemy 1.2 für #4225 identifiziert und behoben. Jedoch berücksichtigten die in dieser Korrektur erkannten Fehlerarten keine BaseException, sondern nur Exception, was verhinderte, dass Eventlet/Gevent Timeout abgefangen wurde. Darüber hinaus wurde ein Block während der initialen Pool-Verbindung identifiziert und mit einem Block BaseException -> „saubere fehlgeschlagene Verbindung“ 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.

  Diese Änderung wird auch zurückportiert nach: 1.4.46

  Referenzen: #8974

• [engine] [bug]

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

  Diese Änderung wird auch zurückportiert nach: 1.4.45

  Referenzen: #8963

sql

• [sql] [usecase]

  Im Falle eines Fehlers bei einem „literal bindparam“-Render-Vorgang wird nun ein informativer Re-Raise ausgelöst, der den Wert selbst und den verwendeten Datentyp angibt, um bei der Fehlersuche zu helfen, wenn literale Parameter in einer Anweisung gerendert werden.

  Diese Änderung wird auch zurückportiert nach: 1.4.45

  Referenzen: #8800

• [sql] [bug]

  Behoben ein Problem in der Lambda-SQL-Funktion, bei dem der berechnete Typ eines literalen Werts die Typumwandlungsregeln des „vergleich mit Typ“ nicht berücksichtigte, was zu fehlenden Typinformationen für SQL-Ausdrücke führte, wie z. B. Vergleiche mit JSON-Elementen und ähnlichem.

  Diese Änderung wird auch zurückportiert nach: 1.4.46

  Referenzen: #9029

• [sql] [bug]

  Behoben eine Reihe von Problemen bezüglich der Position und manchmal der Identität von gerenderten gebundenen Parametern, wie sie 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 „Verschachtelungs“-Funktion des CTE-Konstrukts, das erstmals in #4123 eingeführt wurde, und auswählbare Tabellen, die durch Verwendung der Methode FunctionElement.column_valued() mit Oracle gebildet wurden.

  Diese Änderung wird auch zurückportiert nach: 1.4.45

  Referenzen: #8827

• [sql] [bug]

  Testunterstützung wurde hinzugefügt, um sicherzustellen, dass alle visit_xyz()-Methoden des Compilers in allen Compiler-Implementierungen in SQLAlchemy einen Parameter **kw akzeptieren, sodass alle Compiler zusätzliche Schlüsselwortargumente unter allen Umständen akzeptieren.

  Referenzen: #8988

• [sql] [bug]

  Die Methode SQLCompiler.construct_params() sowie der SQLCompiler.params-Accessor geben nun die exakten Parameter zurück, die einer kompilierten Anweisung entsprechen, die den Parameter render_postcompile zur Kompilierung verwendet hat. Zuvor gab die Methode eine Parameterstruktur zurück, die für sich allein weder den ursprünglichen Parametern noch den erweiterten Parametern entsprach.

  Das Übergeben eines neuen Parameter-Wörterbuchs an SQLCompiler.construct_params() für einen SQLCompiler, der mit render_postcompile konstruiert wurde, ist nun nicht mehr zulässig. Stattdessen wird eine neue Methode SQLCompiler.construct_expanded_state() hinzugefügt, die eine neue erweiterte Form für den gegebenen Parametersatz erzeugt. Diese Methode verwendet den Container ExpandedState, der eine neue SQL-Anweisung und ein neues Parameter-Wörterbuch sowie ein Tupel positionsbezogener Parameter enthält.

  Referenzen: #6114

• [sql] [bug]

  Um Drittanbieter-Dialekte mit unterschiedlichen Anforderungen an die Zeichen-Escapierung für gebundene Parameter zu unterstützen, wurde das System, mit dem SQLAlchemy spezielle Zeichen in Namen von gebundenen Parametern „escapiert“ (d. h. durch ein anderes Zeichen ersetzt), auf Drittanbieter-Dialekte erweiterbar gemacht. Dies geschieht über das Wörterbuch SQLCompiler.bindname_escape_chars, das auf Klassenebene jeder SQLCompiler-Unterklasse überschrieben werden kann. Als Teil dieser Änderung wurde auch der Punkt "." als standardmäßig „escaped“ Zeichen hinzugefügt.

  Referenzen: #8994

typing

• [typing] [bug]

  PEP-484-Typisierung wurde für die Erweiterung sqlalchemy.ext.horizontal_shard sowie für das Modul sqlalchemy.orm.events abgeschlossen. Vielen Dank an Gleb Kisenkov für seine Bemühungen.

  Referenzen: #6810, #9025

asyncio

• [asyncio] [bug]

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

  Diese Änderung wird auch zurückportiert nach: 1.4.45

  Referenzen: #8952

postgresql

• [postgresql] [bug]

  Behobene einen Fehler, bei dem der PostgreSQL-Parameter Insert.on_conflict_do_update.constraint ein Index-Objekt akzeptierte, dieses aber nicht in seine einzelnen Indexausdrücke aufteilte, sondern stattdessen seinen Namen in einer ON CONFLICT ON CONSTRAINT-Klausel rendert, was von PostgreSQL nicht akzeptiert wird; die Form „Constraint-Name“ akzeptiert nur Namen eindeutiger oder ausschließender Constraints. Der Parameter akzeptiert weiterhin den Index, dehnt ihn aber nun für das Rendering in seine einzelnen Ausdrücke auf.

  Diese Änderung wird auch zurückportiert nach: 1.4.46

  Referenzen: #9023

• [postgresql] [bug]

  Eine Anpassung wurde vorgenommen, wie der PostgreSQL-Dialekt Spaltentypen berücksichtigt, wenn er Spalten aus einer Tabelle spiegelt, um alternative Backends zu unterstützen, die NULL von der PG-Funktion format_type() zurückgeben könnten.

  Diese Änderung wird auch zurückportiert nach: 1.4.45

  Referenzen: #8748

• [postgresql] [bug]

  Unterstützung für die explizite Verwendung von PG-Volltextfunktionen mit asyncpg und psycopg (nur SQLAlchemy 2.0) wurde hinzugefügt, bezüglich des REGCONFIG-Typ-Casts für das erste Argument, das zuvor fälschlicherweise als VARCHAR gecastet wurde, was zu Fehlern bei Dialekten führte, die auf explizite Typ-Casts angewiesen sind. Dies beinhaltet die Unterstützung für to_tsvector, to_tsquery, plainto_tsquery, phraseto_tsquery, websearch_to_tsquery, ts_headline. Jede dieser Funktionen bestimmt anhand der Anzahl der übergebenen Argumente, ob das erste String-Argument als PostgreSQL „REGCONFIG“-Wert interpretiert werden soll; falls ja, wird das Argument mit einem neu hinzugefügten Typobjekt REGCONFIG typisiert, das dann im SQL-Ausdruck explizit gecastet wird.

  Referenzen: #8977

• [postgresql] [bug]

  Behoben einen Rückschritt, bei dem neu überarbeitete PostgreSQL-Bereichstypen wie INT4RANGE nicht als Implementierung eines benutzerdefinierten Typs TypeDecorator eingerichtet werden konnten und stattdessen einen TypeError auslösten.

  Referenzen: #9020

• [postgresql] [bug]

  Die Methode Range.__eq___() gibt nun NotImplemented zurück, wenn mit einer Instanz einer anderen Klasse verglichen wird, anstatt eine AttributeError Ausnahme auszulösen.

  Referenzen: #8984

sqlite

• [sqlite] [usecase]

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

  Diese Änderung wird auch zurückportiert nach: 1.4.45

  Referenzen: #8903

• [sqlite] [usecase]

  Unterstützung für die Spiegelung von WHERE-Kriterien, die auf Ausdrücken basieren und in Indizes enthalten sind, im SQLite-Dialekt wurde hinzugefügt, ähnlich dem PostgreSQL-Dialekt. Pull Request von Tobias Pfeiffer.

  Diese Änderung wird auch zurückportiert nach: 1.4.45

  Referenzen: #8804

oracle

• [oracle] [bug]

  Behoben ein Problem im Oracle-Compiler, bei dem die Syntax für FunctionElement.column_valued() falsch war und den Namen COLUMN_VALUE rendert, ohne die Quellentabelle korrekt zu qualifizieren.

  Diese Änderung wird auch zurückportiert nach: 1.4.45

  Referenzen: #8945

tests

• [tests] [bug]

  Behoben ein Problem in der tox.ini-Datei, bei dem Änderungen in der tox 4.0-Serie am Format von „passenv“ dazu führten, dass tox nicht korrekt funktionierte, insbesondere seit tox 4.0.6 eine Fehlermeldung auslöste.

  Diese Änderung wird auch zurückportiert nach: 1.4.46

• [tests] [bug]

  Eine neue Ausschlussregel für Drittanbieter-Dialekte namens unusual_column_name_characters wurde hinzugefügt. Diese Regel kann für Drittanbieter-Dialekte „geschlossen“ werden, die Spaltennamen mit ungewöhnlichen Zeichen wie Punkten, Schrägstrichen oder Prozentzeichen nicht unterstützen, selbst wenn der Name korrekt zitiert ist.

  Diese Änderung wird auch zurückportiert nach: 1.4.46

  Referenzen: #9002

2.0.0b4

Veröffentlicht: 5. Dezember 2022

orm

• [orm] [feature]

  Ein neuer Parameter mapped_column.use_existing_column wurde hinzugefügt, um den Anwendungsfall einer Single-Table-Inheritance-Zuordnung zu unterstützen, die das Muster verwendet, dass mehr als eine Unterklasse dieselbe Spalte für die Oberklasse angibt. Dieses Muster war zuvor möglich durch die Verwendung von declared_attr() in Verbindung mit der Lokalisierung der vorhandenen Spalte in der .__table__ der Oberklasse. Es wurde nun aktualisiert, um auch mit mapped_column() und PEP-484-Typisierung auf einfache und prägnante Weise zu funktionieren.

  Siehe auch

  Auflösung von Spaltenkonflikten mit use_existing_column

  Referenzen: #8822

• [orm] [usecase]

  Unterstützung für benutzerdefinierte Typen, die von der Python-Basisklasse enum.Enum abgeleitet sind, wurde hinzugefügt, um sie automatisch auf SQLAlchemy Enum SQL-Typen abzubilden, wenn die Annotated Declarative Table-Funktion verwendet wird. Die Funktion wird durch neue Lookup-Funktionen im ORM-Typ-Map-Feature ermöglicht und umfasst die Unterstützung für die Änderung der Argumente des Enum, das standardmäßig generiert wird, sowie für die Einrichtung spezifischer enum.Enum-Typen in der Map mit spezifischen Argumenten.

  Siehe auch

  Verwendung von Python Enum oder pep-586 Literal-Typen in der Typ-Map

  Referenzen: #8859

• [orm] [usecase]

  Der Parameter mapped_column.compare wurde zu relevanten ORM-Attributkonstrukten wie mapped_column(), relationship() usw. hinzugefügt, um den Parameter compare von Python-Dataclasses für field() bereitzustellen, wenn die Funktion Declarative Dataclass Mapping verwendet wird. Pull Request von Simon Schiele.

  Referenzen: #8905

• [orm] [bug]

  Behoben ein Problem, bei dem die Verwendung eines unbekannten Datentyps innerhalb einer Mapped-Annotation für ein spaltenbasiertes Attribut lautlos fehlschlug, anstatt eine Ausnahme zu melden; eine informative Ausnahme wird nun ausgelöst.

  Referenzen: #8888

• [orm] [bug]

  Behoben eine Reihe von Problemen, bei denen die Verwendung von Mapped mit Wörterbuchtypen wie Mapped[Dict[str, str] | None] in deklarativen ORM-Zuordnungen nicht korrekt interpretiert wurde. Die Unterstützung zur korrekten „De-Optionalisierung“ dieses Typs, einschließlich der Suche in type_annotation_map, wurde behoben.

  Referenzen: #8777

• [orm] [bug] [performance]

  Weitere Leistungsverbesserungen innerhalb von ORM-aktivierten SQL-Anweisungen, die sich speziell auf Aufrufanzahlen bei der Konstruktion von ORM-Anweisungen konzentrieren. Dies geschieht durch die Kombination von aliased() mit union() und ähnlichen „zusammengesetzten“ Konstrukten, zusätzlich zu direkten Leistungsverbesserungen der internen Methode corresponding_column(), die von ORM-Konstrukten wie aliased() und ähnlichen stark genutzt wird.

  Referenzen: #8796

• [orm] [bug]

  Behoben einen Fehler in der Funktion Declarative Dataclass Mapping, bei dem die Verwendung von einfachen Dataclass-Feldern mit der Direktive __allow_unmapped__ in einer Zuordnung kein Dataclass mit dem korrekten klassenbasierten Zustand für diese Felder erzeugte. Das rohe Field-Objekt wurde unangemessen auf die Klasse kopiert, nachdem Dataclasses selbst das Field-Objekt durch den klassenbasierten Standardwert ersetzt hatten.

  Referenzen: #8880

• [orm] [bug] [regression]

  Behoben einen Rückschritt, bei dem das Flushen einer zugeordneten Klasse, die gegen eine Unterabfrage zugeordnet ist, wie z. B. eine direkte Zuordnung oder einige Formen der konkreten Tabellenvererbung, fehlschlagen würde, wenn der Parameter Mapper.eager_defaults verwendet wurde.

  Referenzen: #8812

• [orm] [bug]

  Behoben einen Rückschritt in 2.0.0b3, der durch #8759 verursacht wurde, bei dem die Angabe des Mapped-Namens mit einem qualifizierten Namen wie sqlalchemy.orm.Mapped von Declarative nicht als Hinweis auf das Mapped-Konstrukt erkannt wurde.

  Referenzen: #8853

orm extensions

• [usecase] [orm extensions]

  Unterstützung für die Erweiterungsfunktion association_proxy() wurde hinzugefügt, um an der Python dataclasses-Konfiguration teilzunehmen, wenn die native Dataclasses-Funktion unter Declarative Dataclass Mapping verwendet wird. Dazu gehören auf Attributebene liegende Argumente wie association_proxy.init und association_proxy.default_factory.

  Die Dokumentation für den Assoziations-Proxy wurde ebenfalls aktualisiert, um in Beispielen "Annotated Declarative Table"-Formulare zu verwenden, einschließlich Typ-Annotationen, die für AssocationProxy selbst verwendet werden.

  Referenzen: #8878

sql

• [sql] [usecase]

  Hinzugefügt: ScalarValues, die als Spaltenelement verwendet werden können, um Values innerhalb von IN-Klauseln oder in Verbindung mit ANY oder ALL-Sammlungsaggregationen zu verwenden. Diese neue Klasse wird über die Methode Values.scalar_values() generiert. Die Values-Instanz wird nun in eine ScalarValues-Instanz umgewandelt, wenn sie in einer IN- oder NOT IN-Operation verwendet wird.

  Referenzen: #6289

• [sql] [bug]

  Kritische Speicherproblem behoben, das bei der Generierung von Cache-Schlüsseln identifiziert wurde. Bei sehr großen und komplexen ORM-Anweisungen, die viele ORM-Aliase mit Unterabfragen verwenden, konnte die Generierung von Cache-Schlüsseln exzessiv große Schlüssel erzeugen, die um Größenordnungen größer waren als die Anweisung selbst. Vielen Dank an Rollo Konig Brock für seine sehr geduldige, langjährige Hilfe bei der endgültigen Identifizierung dieses Problems.

  Diese Änderung wird auch zurückportiert zu: 1.4.44

  Referenzen: #8790

• [sql] [bug]

  Der Ansatz für den numeric pep-249 paramstyle wurde neu geschrieben und wird nun vollständig unterstützt, auch durch Funktionen wie "expanding IN" und "insertmanyvalues". Parameternamen können auch in der Quell-SQL-Konstruktion wiederholt werden, die im numerischen Format mit einem einzigen Parameter korrekt dargestellt werden. Ein zusätzlicher numerischer paramstyle namens numeric_dollar wurde eingeführt, der speziell für die asyncpg-Dialekte verwendet wird; der paramstyle ist äquivalent zu numeric, außer dass numerische Indikatoren durch ein Dollarzeichen anstelle eines Doppelpunkts gekennzeichnet sind. Der asyncpg-Dialekt verwendet nun direkt den numeric_dollar paramstyle, anstatt ihn zuerst in den format-Stil zu kompilieren.

  Die numeric und numeric_dollar paramstyles gehen davon aus, dass das Ziel-Backend in der Lage ist, die numerischen Parameter in beliebiger Reihenfolge zu empfangen, und ordnet die gegebenen Parameterwerte der Anweisung basierend auf der Übereinstimmung ihrer Position (1-basiert) mit dem numerischen Indikator zu. Dies ist das normale Verhalten von "numerischen" paramstyles, obwohl beobachtet wurde, dass der SQLite DBAPI einen nicht verwendeten "numerischen" Stil implementiert, der die Reihenfolge der Parameter nicht berücksichtigt.

  Referenzen: #8849

• [sql] [bug]

  Die Darstellung von RETURNING wurde angepasst, insbesondere bei Verwendung von Insert. Spalten werden nun mit derselben Logik wie beim Select-Konstrukt gerendert, um Labels zu generieren, die auch disambiguierende Labels enthalten, sowie dass eine SQL-Funktion, die eine benannte Spalte umschließt, mit dem Spaltennamen selbst beschriftet wird. Dies schafft eine bessere Kompatibilität beim Auswählen von Zeilen aus Select-Konstrukten oder aus DML-Anweisungen, die UpdateBase.returning() verwenden. Eine engere Änderung wurde auch für die 1.4er-Reihe vorgenommen, die nur das Problem mit der Funktionsbeschriftung behoben hat.

  Referenzen: #8770

schema

• [schema] [bug]

  Strengere Regeln gelten für das Anhängen von Column-Objekten an Table-Objekte. Sowohl frühere Deprecations-Warnungen wurden zu Ausnahmen, als auch einige frühere Szenarien, die dazu führten, dass doppelte Spalten in Tabellen auftraten, wenn Table.extend_existing auf True gesetzt war, sowohl für die programmatische Table-Konstruktion als auch während Reflektionsoperationen.

  Siehe Strengere Regeln für den Ersatz von Spalten in Tabellen-Objekten mit gleichen Namen und Schlüsseln für eine Zusammenfassung dieser Änderungen.

  Siehe auch

  Strengere Regeln für den Ersatz von Spalten in Tabellen-Objekten mit gleichen Namen und Schlüsseln

  Referenzen: #8925

typing

• [typing] [usecase]

  Ein neuer Typ SQLColumnExpression wurde hinzugefügt, der im Benutzercode zur Darstellung von beliebigen spaltenorientierten SQL-Ausdrücken verwendet werden kann, einschließlich solcher, die auf ColumnElement basieren, als auch auf ORM QueryableAttribute. Dieser Typ ist eine echte Klasse, kein Alias, und kann daher auch als Grundlage für andere Objekte dienen. Eine zusätzliche ORM-spezifische Unterklasse SQLORMExpression ist ebenfalls enthalten.

  Referenzen: #8847

• [typing] [bug]

  Interne Verwendung der Python-Klasse enum.IntFlag wurde angepasst, da diese ihren Verhaltensvertrag in Python 3.11 geändert hat. Dies führte nicht zu Laufzeitfehlern, aber zu Fehlern bei Typüberprüfungen unter Python 3.11.

  Referenzen: #8783

• [typing] [bug]

  Die Erweiterungen sqlalchemy.ext.mutable und sqlalchemy.ext.automap sind nun vollständig PEP-484-typisiert. Vielen Dank an Gleb Kisenkov für seine Bemühungen hierbei.

  Referenzen: #6810, #8667

• [typing] [bug]

  Typunterstützung für das Argument relationship.secondary wurde korrigiert, das auch ein Callable (Lambda) akzeptieren kann, das ein FromClause zurückgibt.

• [typing] [bug]

  Die Typisierung für sessionmaker und async_sessionmaker wurde verbessert, sodass der Standardtyp ihres Rückgabewerts Session oder AsyncSession ist, ohne dass dies explizit angegeben werden muss. Zuvor konnte Mypy diese Rückgabetypen nicht automatisch aus seiner generischen Basis ableiten.

  Als Teil dieser Änderung wurden die Argumente für Session, AsyncSession, sessionmaker und async_sessionmaker über das initiale "bind"-Argument hinaus zu schlüsselwortpflichtigen Argumenten gemacht. Dies umfasst Parameter, die immer als schlüsselwortbasierte Argumente dokumentiert waren, wie z. B. Session.autoflush, Session.class_, usw.

  Pull-Request von Sam Bull.

  Referenzen: #8842

• [typing] [bug]

  Problem behoben, bei dem die Übergabe einer aufrufbaren Funktion, die ein Iterable von Spaltenelementen zurückgibt, an relationship.order_by von Typprüfern als Fehler markiert wurde.

  Referenzen: #8776

postgresql

• [postgresql] [usecase]

  Als Ergänzung zu #8690 wurden neue Vergleichsmethoden wie Range.adjacent_to(), Range.difference(), Range.union() usw. zu den PG-spezifischen Range-Objekten hinzugefügt, wodurch diese mit den Standardoperatoren gleichgestellt werden, die von der zugrunde liegenden AbstractRange.comparator_factory implementiert werden.

  Zusätzlich wurde die Methode __bool__() der Klasse korrigiert, um mit dem Verhalten gängiger Python-Container und anderer populärer PostgreSQL-Treiber übereinzustimmen: Sie gibt nun an, ob die Range-Instanz *nicht* leer ist, anstatt umgekehrt.

  Pull-Request von Lele Gaifax.

  Referenzen: #8765

• [postgresql] [change] [asyncpg]

  Der von asyncpg verwendete Paramstyle wurde von format auf numeric_dollar geändert. Dies hat zwei Hauptvorteile, da keine zusätzliche Verarbeitung der Anweisung erforderlich ist und doppelte Parameter in den Anweisungen vorhanden sein können.

  Referenzen: #8926

• [postgresql] [bug] [mssql]

  Nur für die PostgreSQL- und SQL Server-Dialekte wurde der Compiler so angepasst, dass beim Rendern von Spaltenausdrücken in der RETURNING-Klausel das "nicht anonyme" 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 werden kann, 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, #6710 geändert hatte. Der Oracle-Dialekt hat eine andere RETURNING-Implementierung und war von diesem Problem nicht betroffen. Version 2.0 bietet eine übergreifende Änderung für seine weit verbreitete Unterstützung von RETURNING auf anderen Backends.

  Diese Änderung wird auch zurückportiert zu: 1.4.44

  Referenzen: #8770

• [postgresql] [bug]

  Zusätzliche Typenerkennung für den neuen PostgreSQL Range-Typ wurde hinzugefügt. Frühere Fälle, die es erlaubten, dass native psycopg2-Bereichsobjekte direkt vom DBAPI empfangen wurden, ohne dass SQLAlchemy sie abfing, funktionierten nicht mehr, da wir nun ein eigenes Wertobjekt haben. Das Range-Objekt wurde erweitert, so dass SQLAlchemy Core es in ansonsten mehrdeutigen Situationen (z. B. beim Vergleich mit Daten) erkennt und entsprechende Bindungshandler anwendet. Pull-Request von Lele Gaifax.

  Referenzen: #8884

mssql

• [mssql] [bug]

  Regression behoben, die durch die Kombination von #8177 (Wiederaktivierung von setinputsizes für SQL Server, es sei denn, fast_executemany + DBAPI executemany wird für eine Anweisung verwendet) und #6047 (Implementierung von "insertmanyvalues", das DBAPI executemany durch eine benutzerdefinierte DBAPI-Ausführung für INSERT-Anweisungen umgeht) verursacht wurde. setinputsizes wäre bei einer Mehrfachparameter-INSERT-Anweisung, die "insertmanyvalues" verwendete, fälschlicherweise nicht verwendet worden, wenn fast_executemany aktiviert war, da die Prüfung fälschlicherweise davon ausging, dass es sich um einen DBAPI-executemany-Aufruf handelt. Die "Regression" wäre dann, dass das "insertmanyvalues"-Anweisungsformat anscheinend etwas empfindlicher auf mehrere Zeilen reagiert, die nicht die gleichen Typen für jede Zeile verwenden, so dass setinputsizes in einem solchen Fall besonders benötigt wird.

  Die Korrektur behebt die Prüfung von fast_executemany, sodass setinputsizes nur dann deaktiviert wird, wenn echtes DBAPI executemany verwendet werden soll.

  Referenzen: #8917

oracle

• [oracle] [bug]

  Fortgesetzte Korrekturen für Oracle-Fix #8708, veröffentlicht in 1.4.43, bei dem gebundene Parameternamen, die mit Unterstrichen beginnen und von Oracle nicht zugelassen werden, immer noch nicht unter allen Umständen ordnungsgemäß escaped wurden.

  Diese Änderung wird auch zurückportiert nach: 1.4.45

  Referenzen: #8708

tests

• [tests] [bug]

  Problem behoben, bei dem der Parameter --disable-asyncio für die Testsuite die grünenlet-Tests nicht tatsächlich nicht ausführte und auch die Verwendung eines "umschließenden" grünenlets für die gesamte Suite nicht verhinderte. Dieser Parameter stellt nun sicher, dass bei Einstellung keine grünenlet- oder asyncio-Nutzung während des gesamten Laufs erfolgt.

  Diese Änderung wird auch zurückportiert zu: 1.4.44

  Referenzen: #8793

2.0.0b3

Veröffentlicht: 4. November 2022

orm

• [orm] [bug]

  Problem bei der "joined eager loading" behoben, bei dem eine Assertionsverletzung mit einer bestimmten Kombination aus äußeren/inneren joined eager loads auftrat, wenn eager loading über drei Mapper erfolgte, wobei der mittlere Mapper ein vererbter Unterklassen-Mapper war.

  Diese Änderung wird auch zurückportiert zu: 1.4.43

  Referenzen: #8738

• [orm] [bug]

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

  Diese Änderung wird auch zurückportiert zu: 1.4.43

  Referenzen: #8721

• [orm] [bug]

  Eine informative Ausnahme wird nun ausgelöst, wenn die Option with_loader_criteria() als Ladeoption zu einem bestimmten "Ladepfad" hinzugefügt wird, z. B. bei Verwendung in Load.options(). Diese Verwendung wird nicht unterstützt, da with_loader_criteria() nur als Top-Level-Ladeoption vorgesehen ist. Zuvor wurde ein interner Fehler generiert.

  Diese Änderung wird auch zurückportiert zu: 1.4.43

  Referenzen: #8711

• [orm] [bug]

  Der "dictionary mode" für Session.get() wurde verbessert, sodass Synonymnamen, die auf Primärschlüsselattribute verweisen, im benannten Dictionary angegeben werden können.

  Diese Änderung wird auch zurückportiert zu: 1.4.43

  Referenzen: #8753

• [orm] [bug]

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

  Diese Änderung wird auch zurückportiert zu: 1.4.43

  Referenzen: #8704

• [orm] [bug]

  Problem behoben, bei dem der zugrunde liegende DBAPI-Cursor nicht geschlossen wurde, wenn das Query-Objekt als Iterator verwendet wurde, wenn eine benutzerspezifische Ausnahme während der Iteration ausgelöst wurde, was dazu führte, dass der Iterator vom Python-Interpreter geschlossen wurde. Bei Verwendung von Query.yield_per() zum Erstellen von serverseitigen Cursorn führte dies zu den üblichen MySQL-bezogenen Problemen mit serverseitigen Cursorn, die nicht synchron sind, und ohne direkten Zugriff auf das Result-Objekt konnte der Endbenutzercode nicht auf den Cursor zugreifen, um ihn zu schließen.

  Zur Behebung wurde eine Behandlung für GeneratorExit in der Iterator-Methode implementiert, die das Ergebnisobjekt in diesen Fällen schließt, wenn der Iterator unterbrochen wurde und per Definition vom Python-Interpreter geschlossen wird.

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

  Diese Änderung wird auch zurückportiert zu: 1.4.43

  Referenzen: #8710

orm declarative

• [orm] [declarative] [bug]

  Unterstützung in ORM-deklarativen Annotationen für Klassennamen, die für relationship() angegeben wurden, sowie für den Namen des Mapped-Symbols selbst, hinzugefügt, um unterschiedliche Namen als ihre direkten Klassennamen zu unterstützen. Dies dient zur Unterstützung von Szenarien, in denen Mapped als from sqlalchemy.orm import Mapped as M importiert wird, oder wo verwandte Klassennamen auf ähnliche Weise mit einem alternativen Namen importiert werden. Darüber hinaus wird ein Zielklassenname, der als erstes Argument für relationship() angegeben wird, immer den Namen in der linken Annotation überschreiben, sodass auch unimportierbare Namen, die nicht mit dem Klassennamen übereinstimmen, in Annotationen verwendet werden können.

  Referenzen: #8759

• [orm] [declarative] [bug]

  Verbesserte Unterstützung für Legacy-1.4-Mappings, die Annotationen verwenden, die nicht Mapped[] enthalten. Es wird sichergestellt, dass das Attribut __allow_unmapped__ verwendet werden kann, um solche Legacy-Annotationen ohne Fehler durch Annotated Declarative zu lassen und sie nicht im ORM-Laufzeitkontext zu interpretieren. Zusätzlich wurde die Fehlermeldung verbessert, die bei Erkennung dieser Bedingung generiert wird, und weitere Dokumentation hinzugefügt, wie diese Situation gehandhabt werden sollte. Leider kann die 1.4er-Migration-Warnung WARN_SQLALCHEMY_20 dieses spezielle Konfigurationsproblem zur Laufzeit mit ihrer aktuellen Architektur nicht erkennen.

  Referenzen: #8692

• [orm] [declarative] [bug]

  Ein grundlegendes Konfigurationsverhalten von Mapper wurde geändert. Column-Objekte, die explizit im Wörterbuch Mapper.properties vorhanden sind, entweder direkt oder innerhalb eines Mapper-Eigenschaftsobjekts, werden nun in der Reihenfolge ihres Erscheinens in der zugeordneten Table (oder einer anderen auswählbaren) selbst zugeordnet (vorausgesetzt, sie sind Teil der Spaltenliste dieser Tabelle). Dadurch wird die gleiche Reihenfolge der Spalten in der zugeordneten auswählbaren wie auf der zugeordneten Klasse abgebildet und in einer ORM SELECT-Anweisung für diesen Mapper gerendert. Zuvor (seit Version 0.0.1) wurden Column-Objekte im Wörterbuch Mapper.properties immer zuerst zugeordnet, bevor die anderen Spalten der zugeordneten Table zugeordnet wurden. Dies führte zu einer Diskrepanz in der Reihenfolge, in der der Mapper Attribute der zugeordneten Klasse zuordnete, sowie in der Reihenfolge, in der sie in Anweisungen gerendert wurden.

  Die Änderung erfolgt hauptsächlich in der Art und Weise, wie Declarative deklarierte Spalten dem Mapper zuordnet, insbesondere wie Column (oder mapped_column()) Objekte behandelt werden, wenn sie einen DDL-Namen haben, der sich explizit vom abgebildeten Attributnamen unterscheidet, sowie wenn Konstrukte wie deferred() usw. verwendet werden. Das neue Verhalten sieht vor, dass die Spaltenreihenfolge innerhalb der abgebildeten Table die gleiche ist wie die Reihenfolge, in der die Attribute der Klasse zugeordnet werden, die innerhalb des Mapper selbst zugewiesen werden, und die in ORM-Anweisungen wie SELECT-Anweisungen gerendert werden, unabhängig davon, wie die Column dem Mapper zugeordnet wurde.

  Referenzen: #8705

• [orm] [declarative] [bug]

  Problem behoben, bei dem bei der neuen Funktion für die Zuordnung von Datenklassen eine auf der Deklarativbasis / abstrakten Basis / Mixin deklarierte Spalte unter bestimmten Umständen in den Konstruktor einer erbenden Unterklasse "durchsickern" konnte.

  Referenzen: #8718

• [bug] [orm declarative]

  Probleme innerhalb des deklarativen Typen-Resolvers (d. h. der ForwardRef-Objekte auflöst) behoben, bei denen Typen, die für Spalten in einer bestimmten Quelldatei deklariert wurden, NameError auslösten, wenn die endgültige zugeordnete Klasse in einer anderen Quelldatei lag. Die Typen werden nun im Hinblick auf das Modul für jede Klasse aufgelöst, in der die Typen verwendet werden.

  Referenzen: #8742

engine

• [engine] [feature]

  Um den Anwendungsfall der Iteration von Result und AsyncResult Objekten besser zu unterstützen, bei denen benutzerdefinierte Ausnahmen die Iteration unterbrechen können, unterstützen nun beide Objekte sowie Varianten wie ScalarResult, MappingResult, AsyncScalarResult, AsyncMappingResult die Verwendung als Kontextmanager, wobei das Ergebnis am Ende des Kontextmanager-Blocks geschlossen wird.

  Zusätzlich wurde sichergestellt, dass alle oben genannten Result Objekte eine Result.close() Methode sowie Result.closed Accessoren enthalten, einschließlich ScalarResult und MappingResult, die zuvor keine .close() Methode hatten.

  Siehe auch

  Kontextmanager-Unterstützung für Result, AsyncResult

  Referenzen: #8710

• [engine] [usecase]

  Neuer Parameter PoolEvents.reset.reset_state wurde dem PoolEvents.reset() Event hinzugefügt, mit aktivierter Deprecationslogik, die weiterhin Event-Hooks mit der vorherigen Argumentenliste akzeptiert. Dieser Parameter gibt verschiedene Statusinformationen darüber an, wie der Reset durchgeführt wird, und ermöglicht benutzerdefinierte Reset-Schemata mit vollständigem Kontext.

  Innerhalb dieser Änderung ist eine Korrektur enthalten, die auch nach 1.4 zurückportiert wird und das PoolEvents.reset() Event wieder aktiviert, damit es unter allen Umständen weiterhin stattfindet, auch wenn die Connection die Verbindung bereits „zurückgesetzt“ hat.

  Die beiden Änderungen zusammen ermöglichen die Implementierung benutzerdefinierter Reset-Schemata unter Verwendung des PoolEvents.reset() Events, anstatt des PoolEvents.checkin() Events (das weiterhin wie gewohnt funktioniert).

  Referenzen: #8717

• [engine] [bug] [regression]

  Problem behoben, bei dem der Hook für das PoolEvents.reset() Event nicht in allen Fällen aufgerufen wurde, wenn eine Connection geschlossen wurde und die DBAPI-Verbindung gerade an den Connection-Pool zurückgegeben wurde.

  Das Szenario trat auf, wenn die Connection bereits .rollback() auf ihrer DBAPI-Verbindung ausgelöst hatte, während die Verbindung an den Pool zurückgegeben wurde. Dabei wurde dem Connection-Pool angewiesen, sein eigenes „Reset“ zu überspringen, um den zusätzlichen Methodenaufruf zu sparen. Dies verhinderte jedoch die Verwendung benutzerdefinierter Pool-Reset-Schemata innerhalb dieses Hooks, da solche Hooks per Definition mehr tun, als nur .rollback() aufzurufen, und unter allen Umständen aufgerufen werden müssen. Dies war eine Regression, die in Version 1.4 auftrat.

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

  Diese Änderung wird auch zurückportiert zu: 1.4.43

  Referenzen: #8717

sql

• [sql] [bug]

  Problem behoben, das verhinderte, dass die literal_column()-Konstruktion im Kontext einer Select-Konstruktion und an anderen Stellen, an denen „anonyme Labels“ generiert werden könnten, korrekt funktionierte, wenn der literale Ausdruck Zeichen enthielt, die mit Format-Strings kollidieren könnten, wie z. B. eine öffnende Klammer, aufgrund eines Implementierungsdetails der „anonymen Label“-Struktur.

  Diese Änderung wird auch zurückportiert zu: 1.4.43

  Referenzen: #8724

typing

• [typing] [bug]

  Verschiedene Typisierungsfehler in den Paketen `engine` und `async engine` behoben.

postgresql

• [postgresql] [feature]

  Neue Methoden Range.contains() und Range.contained_by() wurden dem neuen Datenobjekt Range hinzugefügt. Diese spiegeln das Verhalten der PostgreSQL-Operatoren @> und <@ sowie die SQL-Operator-Methoden comparator_factory.contains() und comparator_factory.contained_by() wider. Pull Request von Lele Gaifax.

  Referenzen: #8706

• [postgresql] [usecase]

  Der neue Ansatz für Range-Objekte, der unter New RANGE / MULTIRANGE support and changes for PostgreSQL backends beschrieben wurde, wurde verfeinert, um Treiber-spezifische Range- und Multirange-Objekte zu unterstützen. Dies dient dazu, sowohl Legacy-Code als auch die Übergabe von Ergebnissen aus rohen SQL-Resultsets in neue Range- oder Multirange-Ausdrücke besser zu handhaben.

  Referenzen: #8690

mssql

• [mssql] [bug]

  Problem behoben mit Inspector.has_table(), welches bei Verwendung gegen temporäre Tabellen mit dem SQL Server Dialekt bei einigen Azure-Varianten fehlschlug, aufgrund einer unnötigen Abfrage des Informationsschemas, die auf diesen Serverversionen nicht unterstützt wird. Pull Request von Mike Barry.

  Diese Änderung wird auch zurückportiert zu: 1.4.43

  Referenzen: #8714

• [mssql] [bug] [reflection]

  Problem behoben mit Inspector.has_table(), welches bei Verwendung gegen eine View mit dem SQL Server Dialekt fälschlicherweise False zurückgab. Dies war eine Regression in der 1.4-Serie, die die Unterstützung dafür unter SQL Server entfernte. Die 2.0-Serie, die eine andere Reflexionsarchitektur verwendet, ist von diesem Problem nicht betroffen. Testunterstützung wurde hinzugefügt, um sicherzustellen, dass has_table() gemäß Spezifikation bezüglich Views weiterhin funktioniert.

  Diese Änderung wird auch zurückportiert zu: 1.4.43

  Referenzen: #8700

oracle

• [oracle] [bug]

  Problem behoben, bei dem gebundene Parameternamen, einschließlich derer, die automatisch aus ähnlich benannten Datenbankspalten abgeleitet wurden und Zeichen enthielten, die bei Oracle normalerweise Anführungszeichen erfordern, bei Verwendung von „expandierenden Parametern“ mit dem Oracle-Dialekt nicht maskiert wurden, was zu Ausführungsfehlern führte. Die übliche „Maskierung“ für gebundene Parameter, die vom Oracle-Dialekt verwendet wird, wird bei der „expandierenden Parameter“-Architektur nicht verwendet. Daher wird nun eine Liste von Zeichen/Maskierungen verwendet, die spezifisch für Oracle sind, um eine große Bandbreite von Zeichen zu maskieren.

  Diese Änderung wird auch zurückportiert zu: 1.4.43

  Referenzen: #8708

• [oracle] [bug]

  Problem behoben, bei dem die Ansicht nls_session_parameters, die beim ersten Verbindungsaufbau abgefragt wurde, 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, um direkt einen Dezimalwert zu testen, anstatt Systemansichten zu lesen, was auf jedem Backend/Treiber funktioniert.

  Diese Änderung wird auch zurückportiert zu: 1.4.43

  Referenzen: #8744

2.0.0b2

Veröffentlicht: 20. Oktober 2022

orm

• [orm] [bug]

  Die Warnung, die beim Verwenden von ORM-fähigen Update/Delete-Anweisungen bezüglich der Auswertung von Spalten nach Namen ausgelöst wurde (zuerst hinzugefügt in #4073), wurde entfernt. Diese Warnung deckte tatsächlich ein Szenario ab, das andernfalls den falschen Python-Wert für ein ORM-abgebildetes Attribut populiert hätte, abhängig von der tatsächlichen Spalte. Daher wurde dieser veraltete Fall entfernt. In 2.0 verwenden ORM-fähige Update/Delete-Anweisungen „auto“ für „synchronize_session“, was für jede gegebene UPDATE-Anweisung automatisch das Richtige tun sollte.

  Referenzen: #8656

orm declarative

• [orm] [declarative] [usecase]

  Unterstützung für abgebildete Klassen hinzugefügt, die auch Generic-Unterklassen sind, um als GenericAlias-Objekt (z. B. MyClass[str]) in Anweisungen und Aufrufen von inspect() angegeben zu werden.

  Referenzen: #8665

• [orm] [declarative] [bug]

  Die Klasse DeclarativeBase wurde verbessert, sodass bei Kombination mit anderen Mixins wie MappedAsDataclass die Reihenfolge der Klassen beliebig sein kann.

  Referenzen: #8665

• [orm] [declarative] [bug]

  Fehler in neuen ORM-typisierten deklarativen Abbildungen behoben, bei dem die Möglichkeit, Optional[MyClass] oder ähnliche Formen wie MyClass | None in der Typannotation für eine Many-to-One-Beziehung zu verwenden, nicht implementiert war, was zu Fehlern führte. Dokumentation für diesen Anwendungsfall wurde auch zu den Dokumenten zur Konfiguration von Beziehungen hinzugefügt.

  Referenzen: #8668

• [orm] [declarative] [bug]

  Problem behoben mit der neuen Dataclass-Mapping-Funktion, bei der Argumente, die an die Dataclasses API übergeben wurden, bei der Behandlung von Mixins, die mapped_column()-Deklarationen überschreiben, manchmal falsch geordnet werden konnten, was zu Initialisierungsproblemen führte.

  Referenzen: #8688

sql

• [sql] [bug] [regression]

  Fehler in der neuen „insertmanyvalues“-Funktion behoben, bei der INSERT-Anweisungen, die eine Subquery mit bindparam() enthielten, im „insertmanyvalues“-Format nicht korrekt gerendert wurden. Dies betraf vor allem `psycopg2`, da „insertmanyvalues“ mit diesem Treiber bedingungslos verwendet wird.

  Referenzen: #8639

typing

• [typing] [bug]

  Typisierungsfehler behoben, bei dem der strenge Modus von Pylance „instance variable overrides class variable“ meldete, wenn eine Methode verwendet wurde, um __tablename__, __mapper_args__ oder __table_args__ zu definieren.

  Referenzen: #8645

• [typing] [bug]

  Typisierungsfehler behoben, bei dem der strenge Modus von Pylance für den mapped_column()-Konstrukt einen „teilweise unbekannten“ Datentyp meldete.

  Referenzen: #8644

mssql

• [mssql] [bug]

  Regression behoben, verursacht durch die Änderung #8177 in SQL Server pyodbc, bei der wir nun standardmäßig setinputsizes() verwenden. Für VARCHAR schlägt dies fehl, wenn die Zeichengröße 4000 (oder 2000, je nach Daten) Zeichen übersteigt, da der eingehende Datentyp NVARCHAR ist, der eine Grenze von 4000 Zeichen hat, obwohl VARCHAR unbegrenzte Zeichen verarbeiten kann. Zusätzliche pyodbc-spezifische Typinformationen werden nun an setinputsizes() übergeben, wenn die Größe des Datentyps > 2000 Zeichen beträgt. Die Änderung wird auch auf den JSON-Typ angewendet, der ebenfalls von diesem Problem bei großen JSON-Serialisierungen betroffen war.

  Referenzen: #8661

• [mssql] [bug]

  Die Sequence-Konstruktion stellt das DDL-Verhalten wieder her, das sie vor der 1.4-Serie hatte. Wenn eine Sequence ohne zusätzliche Argumente erstellt wird, wird eine einfache CREATE SEQUENCE-Anweisung **ohne** zusätzliche Parameter für den „Startwert“ ausgegeben. Für die meisten Backends funktionierte es ohnehin bereits so; **jedoch** ist für MS SQL Server der Standardwert auf dieser Datenbank -2**63. Um diesen im Allgemeinen unpraktischen Standardwert auf SQL Server zu vermeiden, sollte der Parameter Sequence.start angegeben werden. Da die Verwendung von Sequence für SQL Server ungewöhnlich ist, der seit vielen Jahren auf IDENTITY standardisiert hat, wird gehofft, dass diese Änderung minimale Auswirkungen hat.

  Siehe auch

  Die Sequence-Konstruktion kehrt zum Zustand ohne expliziten Standard-"Start"-Wert zurück; betrifft MS SQL Server

  Referenzen: #7211

2.0.0b1

Veröffentlicht: 13. Oktober 2022

general

• [general] [changed]

  Der Code wurde migriert, um alle vor 2.0 liegenden Verhaltensweisen und Architekturen zu entfernen, die zuvor für die Entfernung in 2.0 als veraltet markiert waren, einschließlich, aber nicht beschränkt auf:

  • Entfernung von allem Python-2-Code, Mindestversion ist jetzt Python 3.7

  • Engine und Connection verwenden jetzt den neuen 2.0-Stil der Arbeit, der „autobegin“, die Entfernung von Library-Level-Autocommit, Subtransaktionen und „verzweigte“ Verbindungen beinhaltet.

  • Result-Objekte verwenden 2.0-Stil-Verhaltensweisen; Row ist vollständig ein benanntes Tupel ohne „Mapping“-Verhalten, verwenden Sie RowMapping für „Mapping“-Verhalten.

  • Die gesamte Unicode-Kodierungs-/Dekodierungsarchitektur wurde aus SQLAlchemy entfernt. Alle modernen DBAPI-Implementierungen unterstützen dank Python 3 Unicode transparent. Daher wurden die Funktion convert_unicode sowie verwandte Mechanismen zur Suche nach Bytestrings in cursor.description usw. entfernt.

  • Das Attribut und der Parameter .bind von MetaData, Table und von allen DDL/DML/DQL-Elementen, die zuvor auf eine „gebundene Engine“ verweisen konnten.

  • Die eigenständige Funktion sqlalchemy.orm.mapper() wurde entfernt; alle klassische Abbildung sollte über die Methode registry.map_imperatively() der registry erfolgen.

  • Die Methode Query.join() akzeptiert keine Strings mehr für Beziehungsnamen mehr; der seit langem dokumentierte Ansatz zur Verwendung von Class.attrname für Join-Ziele ist nun Standard.

  • Query.join() akzeptiert die Argumente „aliased“ und „from_joinpoint“ nicht mehr.

  • Query.join() akzeptiert keine Ketten mehrerer Join-Ziele mehr in einem Methodenaufruf.

  • Query.from_self(), Query.select_entity_from() und Query.with_polymorphic() wurden entfernt.

  • Der Parameter relationship.cascade_backrefs muss nun auf seinem neuen Standardwert False bleiben; die save-update Kaskade wird nicht mehr entlang einer Rückreferenz weitergegeben.

  • Der Parameter Session.future muss immer auf True gesetzt sein. 2.0-Stil Transaktionsmuster für Session sind nun immer aktiv.

  • Loader-Optionen akzeptieren keine Strings mehr für Attributnamen. Der seit langem dokumentierte Ansatz zur Verwendung von Class.attrname für Loader-Optionsziele ist nun Standard.

  • Legacy-Formen von select() entfernt, einschließlich select([cols]), der „whereclause“- und Keyword-Parameter von some_table.select().

  • Legacy „in-place mutator“-Methoden auf Select wie append_whereclause(), append_order_by() etc. wurden entfernt.

  • Das sehr alte Modul „dbapi_proxy“ wurde entfernt, das in sehr frühen SQLAlchemy-Versionen verwendet wurde, um einen transparenten Connection-Pool über eine rohe DBAPI-Verbindung bereitzustellen.

  Referenzen: #7257

• [general] [changed]

  Die Methode Query.instances() ist veraltet. Der Verhaltensvertrag dieser Methode, nämlich dass sie Objekte über beliebige Result-Sets iterieren kann, ist längst obsolet und wird nicht mehr getestet. Beliebige Anweisungen können Objekte über Konstrukte wie :meth`.Select.from_statement` oder aliased() zurückgeben.

platform

• [platform] [feature]

  Die SQLAlchemy C-Erweiterungen wurden durch komplett neue Implementierungen in Cython ersetzt. Ähnlich wie die C-Erweiterungen zuvor sind vorgefertigte Wheel-Dateien für eine breite Palette von Plattformen auf PyPI verfügbar, sodass die Kompilierung für gängige Plattformen kein Problem darstellt. Für benutzerdefinierte Builds funktioniert python setup.py build_ext wie zuvor und benötigt nur die zusätzliche Cython-Installation. pyproject.toml ist nun ebenfalls Teil des Quellcodes, was die richtigen Build-Abhängigkeiten bei der Verwendung von pip etabliert.

  Siehe auch

  C Extensions nun auf Cython portiert

  Referenzen: #7256

• [platform] [change]

  Der Quellcode-Build und die Installation von SQLAlchemy enthalten nun eine pyproject.toml-Datei für die vollständige Unterstützung von PEP 517.

  Siehe auch

  Installation nun vollständig PEP-517-fähig

  Referenzen: #7311

orm

• [orm] [feature] [sql]

  Neues Feature für alle enthaltenen Dialekte hinzugefügt, die RETURNING unterstützen, namens „insertmanyvalues“. Dies ist eine Verallgemeinerung des Features „fast executemany“, das erstmals für den psycopg2-Treiber in Version 1.4 unter ORM Batch-Inserts mit psycopg2 schlagen jetzt Statements mit RETURNING in den meisten Fällen zusammen eingeführt wurde. Dieses Feature ermöglicht es dem ORM, INSERT-Statements zu einem deutlich effizienteren SQL-Konstrukt zusammenzufassen, während gleichzeitig neue generierte Primärschlüssel und SQL-Standardwerte mittels RETURNING abgerufen werden können.

  Das Feature gilt nun für die vielen Dialekte, die RETURNING zusammen mit mehreren VALUES-Konstrukten für INSERT unterstützen, einschließlich aller PostgreSQL-Treiber, SQLite, MariaDB und MS SQL Server. Separat erhält der Oracle-Dialekt dieselbe Funktionalität durch native cx_Oracle- oder OracleDB-Features.

  Referenzen: #6047

• [orm] [feature]

  Neuer Parameter AttributeEvents.include_key hinzugefügt, der den Schlüssel des Dictionaries oder der Liste für Operationen wie __setitem__() (z.B. obj[key] = value) und __delitem__() (z.B. del obj[key]) einschließt. Dies geschieht über einen neuen Schlüsselwortparameter „key“ oder „keys“, abhängig vom Event, z.B. AttributeEvents.append.key, AttributeEvents.bulk_replace.keys. Dies ermöglicht Event-Handlern, den Schlüssel zu berücksichtigen, der an die Operation übergeben wurde, und ist von besonderer Bedeutung für Dictionary-Operationen, die mit MappedCollection arbeiten.

  Referenzen: #8375

• [orm] [feature]

  Neuer Parameter Operators.op.python_impl hinzugefügt, verfügbar über Operators.op() und auch bei direkter Verwendung des custom_op-Konstruktors. Dieser ermöglicht die Bereitstellung einer In-Python-Evaluierungsfunktion zusammen mit dem benutzerdefinierten SQL-Operator. Diese Evaluierungsfunktion wird zur Implementierung, die verwendet wird, wenn das Operatorobjekt mit rein Python-Objekten auf beiden Seiten als Operanden verwendet wird. Insbesondere ist dies kompatibel mit der Option synchronize_session='evaluate', die mit ORM-fähige INSERT-, UPDATE- und DELETE-Statements verwendet wird.

  Referenzen: #3162

• [orm] [feature]

  Die Session (und somit auch AsyncSession) verfügt nun über neue Funktionalitäten zur Zustandsverfolgung, die proaktiv unerwartete Zustandsänderungen abfangen, die während der Ausführung einer bestimmten transaktionalen Methode auftreten. Dies soll Situationen ermöglichen, in denen die Session auf nicht threadsichere Weise verwendet wird, wo Event-Hooks oder ähnliches unerwartete Methoden innerhalb von Operationen aufrufen können, sowie unter anderen Nebenläufigkeitssituationen wie asyncio oder gevent, um eine informative Meldung auszugeben, sobald der illegale Zugriff auftritt, anstatt stillschweigend fortzufahren, was zu sekundären Fehlern aufgrund des ungültigen Zustands der Session führt.

  Siehe auch

  Session gibt proaktiv aus, wenn illegale gleichzeitige oder reentrant Zugriffserkennung erfolgt

  Referenzen: #7433

• [orm] [feature]

  Der Mapping-Konstrukt composite() unterstützt nun die automatische Auflösung von Werten, wenn er mit einem Python- dataclass verwendet wird; die Methode __composite_values__() muss nicht mehr implementiert werden, da diese Methode aus der Inspektion des Dataclasses abgeleitet wird.

  Zusätzlich unterstützen Klassen, die von composite gemappt werden, nun Vergleichsoperationen für die Sortierung, z.B. <, >= usw.

  Siehe die neue Dokumentation unter Composite Column Types für Beispiele.

• [orm] [feature]

  Sehr experimentelles Feature zu den Ladeoptionen selectinload() und immediateload() hinzugefügt, genannt selectinload.recursion_depth / immediateload.recursion_depth. Dies ermöglicht es einer einzelnen Ladeoption, sich automatisch in selbstreferenzielle Beziehungen zu rekursiv einzubinden. Wird auf eine Ganzzahl gesetzt, die die Tiefe angibt, und kann auch auf -1 gesetzt werden, um das Laden fortzusetzen, bis keine tieferen Ebenen mehr gefunden werden. Umfangreiche interne Änderungen an selectinload() und immediateload() ermöglichen es diesem Feature, zu funktionieren und weiterhin den Kompilierungs-Cache korrekt zu nutzen, ohne willkürliche Rekursion zu verwenden. Daher wird jede Tiefe unterstützt (obwohl dies so viele Abfragen erzeugen würde). Dies kann für selbstreferenzielle Strukturen nützlich sein, die vollständig eager geladen werden müssen, wie z.B. bei der Verwendung von asyncio.

  Eine Warnung wird auch ausgegeben, wenn Ladeoptionen mit beliebigen Längen miteinander verbunden werden (d.h. ohne die neue Option recursion_depth zu verwenden), wenn eine übermäßige Rekursionstiefe bei der Ladung verwandter Objekte erkannt wird. Diese Operation verbraucht weiterhin riesige Mengen an Speicher und hat extrem schlechte Leistung; der Cache wird deaktiviert, wenn diese Bedingung erkannt wird, um den Cache vor einer Überflutung mit beliebigen Statements zu schützen.

  Referenzen: #8126

• [orm] [feature]

  Neuer Parameter Session.autobegin hinzugefügt. Wenn dieser auf False gesetzt ist, verhindert er, dass die Session implizit eine Transaktion beginnt. Die Methode Session.begin() muss zuerst explizit aufgerufen werden, um mit Operationen fortzufahren, andernfalls wird ein Fehler ausgelöst, sobald eine Operation sonst automatisch begonnen hätte. Diese Option kann verwendet werden, um eine „sichere“ Session zu erstellen, die keine neuen Transaktionen implizit startet.

  Als Teil dieser Änderung wurde auch eine neue Statusvariable origin hinzugefügt, die für Event-Handling-Code nützlich sein kann, um den Ursprung einer bestimmten SessionTransaction zu erkennen.

  Referenzen: #6928

• [orm] [feature]

  Deklarative Mixins, die Column-Objekte verwenden, die ForeignKey-Referenzen enthalten, müssen nicht mehr declared_attr() verwenden, um dieses Mapping zu erreichen. Das ForeignKey-Objekt wird zusammen mit der Column selbst kopiert, wenn die Spalte auf das deklarierte Mapping angewendet wird.

• [orm] [usecase]

  Parameter load_only.raiseload zur Ladeoption load_only() hinzugefügt, sodass die nicht geladenen Attribute „raise“-Verhalten anstelle von Lazy Loading aufweisen können. Zuvor gab es keine Möglichkeit, dies mit der Option load_only() direkt zu tun.

• [orm] [change]

  Um die explizite Typisierung besser zu unterstützen, wurden die Namen einiger ORM-Konstrukte, die typischerweise intern konstruiert werden, aber dennoch in Meldungen sowie in der Typisierung sichtbar sind, in prägnantere Namen geändert, die auch dem Namen ihrer Konstruktionsfunktion (mit anderer Groß-/Kleinschreibung) entsprechen. In allen Fällen werden für absehbare Zeit Aliase zu den alten Namen beibehalten.

  • RelationshipProperty wird zu einem Alias für den primären Namen Relationship, der wie immer aus der Funktion relationship() konstruiert wird.

  • SynonymProperty wird zu einem Alias für den primären Namen Synonym, der wie immer aus der Funktion synonym() konstruiert wird.

  • CompositeProperty wird zu einem Alias für den primären Namen Composite, der wie immer aus der Funktion composite() konstruiert wird.

• [orm] [change]

  Zur besseren Konsistenz mit dem prominenten ORM-Konzept Mapped werden die Namen der Dictionary-orientierten Kollektionen attribute_mapped_collection(), column_mapped_collection() und MappedCollection in attribute_keyed_dict(), column_keyed_dict() und KeyFuncDict geändert, wobei die Phrase „dict“ verwendet wird, um Verwirrung mit dem Begriff „mapped“ zu minimieren. Die alten Namen bleiben auf unbestimmte Zeit bestehen, ohne dass ein Entfernungsplan existiert.

  Referenzen: #8608

• [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 gängigsten Ergebnisobjektklassen für Core-Statement-Ausführungen, d.h. derjenigen, die auf CursorResult basieren, sodass dieses Verhalten nicht neu ist. Die Änderung wurde jedoch erweitert, um ORM-„filtering“-Ergebnisobjekte, die bei Verwendung von ORM-Queries im 2.0-Stil zurückgegeben werden, ordnungsgemäß zu unterstützen. Diese verhielten sich zuvor im „soft closed“-Stil mit Rückgabe leerer Ergebnisse, oder sie „soft closed“en gar nicht und lieferten weiterhin aus dem zugrunde liegenden Cursor.

  Als Teil dieser Änderung wurde auch Result.close() zur Basisklasse Result hinzugefügt und für die gefilterten Ergebnisimplementierungen implementiert, die vom ORM verwendet werden. Dadurch ist es möglich, die Methode CursorResult.close() auf dem 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-Ergebnissets verfügbar, aber die Änderung macht es auch für ORM-Ergebnisse im 2.0-Stil verfügbar.

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

  Referenzen: #7274

• [orm] [bug]

  Problem behoben, bei dem die Methode registry.map_declaratively() ein internes „mapper config“-Objekt zurückgab und nicht das Mapper-Objekt, wie in der API-Dokumentation angegeben.

• [orm] [bug]

  Performance-Regression behoben, die mindestens in Version 1.3, wenn nicht früher (irgendwann nach 1.0), auftrat. Dabei wurde beim Laden von verzögerten Spalten, die explizit mit defer() gemappt wurden (im Gegensatz zu nicht verzögerten Spalten, die abgelaufen waren), nicht die „optimierte“ Abfrage verwendet, die nur die unmittelbare Tabelle abfragt, die die ungeladenen Spalten enthält. Stattdessen wurde eine vollständige ORM-Abfrage ausgeführt, die einen JOIN für alle Basistabellen ausgab, was nicht notwendig ist, wenn nur Spalten aus der Unterklasse geladen werden.

  Referenzen: #7463

• [orm] [bug]

  Die Interna des Load-Objekts und verwandter Lade-Strategie-Muster wurden größtenteils neu geschrieben, um die Tatsache auszunutzen, dass nur Attribut-gebundene Pfade, keine Strings, mehr unterstützt werden. Die Neufassung soll es in Zukunft einfacher machen, neue Anwendungsfälle und subtile Probleme innerhalb des Lade-Strategie-Systems zu adressieren.

  Referenzen: #6986

• [orm] [bug]

  Verbesserung an den Strategie-Optionen „deferred“ / „load_only“ vorgenommen. Wenn ein bestimmtes Objekt über zwei verschiedene logische Pfade innerhalb einer Abfrage geladen wird, werden Attribute, die von mindestens einer der Optionen als zu befüllend konfiguriert wurden, in allen Fällen befüllt, auch wenn andere Lade-Pfade für dasselbe Objekt diese Option nicht gesetzt haben. Zuvor basierte dies auf Zufälligkeit, welcher „Pfad“ das Objekt zuerst ansprach.

  Referenzen: #8166

• [orm] [bug]

  Problem bei ORM-fähigem UPDATE behoben, wenn das Statement gegen eine Joined-Inheritance-Unterklasse erstellt wird und nur lokale Tabellenspalten aktualisiert, wobei die „fetch“-Synchronisierungsstrategie die korrekte RETURNING-Klausel für Datenbanken, die RETURNING für die Fetch-Synchronisierung verwenden, nicht korrekt rendert. Passt auch die verwendete Strategie für RETURNING in UPDATE FROM und DELETE FROM Statements an.

  Referenzen: #8344

• [orm] [bug] [asyncio]

  Die ungenutzten Argumente **kw aus begin und begin_nested wurden entfernt. Diese kw werden nicht verwendet und scheinen fälschlicherweise zur API hinzugefügt worden zu sein.

  Referenzen: #7703

• [orm] [bug]

  Die Attributzugriffsmethode, die von attribute_mapped_collection() und column_mapped_collection() (jetzt attribute_keyed_dict() und column_keyed_dict() genannt) beim Befüllen des Dictionaries verwendet wird, wurde geändert, um zu überprüfen, ob der Datenwert auf dem Objekt, der als Dictionary-Schlüssel verwendet werden soll, tatsächlich vorhanden ist und nicht stattdessen „None“ verwendet wird, weil das Attribut noch nie tatsächlich zugewiesen wurde. Dies dient dazu, eine fehlerhafte Befüllung von None für einen Schlüssel zu verhindern, wenn über eine Rückreferenz zugewiesen wird, bei der das „key“-Attribut des Objekts noch nicht zugewiesen ist.

  Da der Fehlermodus hier eine transiente Bedingung ist, die typischerweise nicht in der Datenbank gespeichert wird und leicht über den Konstruktor der Klasse basierend auf der Reihenfolge der Parameterzuweisung erzeugt werden kann, ist es sehr wahrscheinlich, dass viele Anwendungen dieses Verhalten bereits beinhalten, das stillschweigend übersehen wird. Um Anwendungen zu unterstützen, bei denen dieser Fehler nun ausgelöst wird, wird auch ein neuer Parameter attribute_keyed_dict.ignore_unpopulated_attribute sowohl zu attribute_keyed_dict() als auch zu column_keyed_dict() hinzugefügt, der stattdessen die fehlerhafte Rückreferenzzuweisung überspringt.

  Referenzen: #8372

• [orm] [bug]

  Neuer Parameter AbstractConcreteBase.strict_attrs zur deklarativen Mixin-Klasse AbstractConcreteBase hinzugefügt. Die Auswirkung dieses Parameters ist, dass der Geltungsbereich von Attributen in Unterklassen korrekt auf die Unterklasse beschränkt wird, in der jedes Attribut deklariert ist, im Gegensatz zum vorherigen Verhalten, bei dem alle Attribute der gesamten Hierarchie auf die Basis-"abstrakte" Klasse angewendet wurden. Dies führt zu einem saubereren, korrekteren Mapping, bei dem Unterklassen keine nicht nützlichen Attribute mehr aufweisen, die nur für Geschwisterklassen relevant sind. Der Standardwert für diesen Parameter ist False, wodurch das vorherige Verhalten unverändert bleibt; dies dient zur Unterstützung vorhandener Codes, die diese Attribute explizit in Abfragen verwenden. Um zum neueren Ansatz zu migrieren, wenden Sie explizite Attribute nach Bedarf auf die abstrakte Basisklasse an.

  Referenzen: #8403

• [orm] [bug]

  Das Verhalten von defer() in Bezug auf Primärschlüssel- und „polymorphe Diskriminator“-Spalten wurde überarbeitet, sodass diese Spalten weder explizit noch bei Verwendung eines Wildcards wie defer('*') verzögert werden können. Zuvor wurde bei einer Wildcard-Verzögerung die PK/polymorphen Spalten nicht geladen, was in allen Fällen zu Fehlern führte, da das ORM auf diese Spalten angewiesen ist, um Objektidentitäten zu erzeugen. Das Verhalten der expliziten Verzögerung von Primärschlüsselspalten bleibt unverändert, da diese Verzögerungen bereits implizit ignoriert wurden.

  Referenzen: #7495

• [orm] [bug]

  Bug im Verhalten des Parameters Mapper.eager_defaults behoben, sodass clientseitige SQL-Standardwerte oder onupdate-Ausdrücke allein in der Tabellendefinition eine Abfrage mit RETURNING oder SELECT auslösen, wenn das ORM einen INSERT oder UPDATE für die Zeile emittiert. Zuvor lösten nur serverseitige Standardwerte, die als Teil der Tabellen-DDL und/oder serverseitige onupdate-Ausdrücke festgelegt wurden, diesen Fetch aus, obwohl clientseitige SQL-Ausdrücke enthalten waren, wenn der Fetch gerendert wurde.

  Referenzen: #7438

engine

• [engine] [feature]

  Das Event DialectEvents.handle_error() wurde aus der EngineEvents Suite in die DialectEvents Suite verschoben und nimmt nun am „Pre-Ping“-Event des Connection-Pools teil, für jene Dialekte, die Disconnect-Codes verwenden, um festzustellen, ob die Datenbank erreichbar ist. Dies ermöglicht es Endbenutzercode, den Status von „Pre-Ping“ zu ändern. Beachten Sie, dass dies keine Dialekte umfasst, die eine native „Ping“-Methode enthalten, wie beispielsweise bei psycopg2 oder den meisten MySQL-Dialekten.

  Referenzen: #5648

• [engine] [feature]

  Die Event-Hooks ConnectionEvents.set_connection_execution_options() und ConnectionEvents.set_engine_execution_options() erlauben nun die direkte Modifikation des gegebenen Options-Dictionary, wobei der neue Inhalt als endgültige Ausführungsoptionen übernommen wird. Zuvor waren direkte Modifikationen des Dictionarys nicht unterstützt.

• [engine] [usecase]

  Der Parameter create_engine.isolation_level wurde für den Basisdialekt verallgemeinert, sodass er nicht mehr von einzelnen Dialekten abhängt. Dieser Parameter stellt die „Isolationsebene“ für alle neuen Datenbankverbindungen ein, sobald diese vom Connection-Pool erstellt werden, wobei der Wert dann gesetzt bleibt, ohne bei jedem Check-in zurückgesetzt zu werden.

  Der Parameter create_engine.isolation_level ist funktional äquivalent zur Verwendung des Parameters Engine.execution_options.isolation_level über Engine.execution_options() für eine Motorweite Einstellung. Der Unterschied besteht darin, dass die erstere Einstellung die Isolationsebene nur einmal beim Erstellen einer Verbindung zuweist, während letztere das gegebene Level bei jedem Auschecken einer Verbindung setzt und zurücksetzt.

  Referenzen: #6342

• [engine] [change]

  Einige kleine API-Änderungen bezüglich Engines und Dialekten

  • Die Methoden Dialect.set_isolation_level(), Dialect.get_isolation_level(), :meth: Dialektmethoden werden immer mit der rohen DBAPI-Verbindung aufgerufen

  • Die Klassen Connection und Engine teilen sich nicht mehr eine gemeinsame Basisklasse Connectable, welche entfernt wurde.

  • Eine neue Schnittstellenklasse PoolProxiedConnection wurde hinzugefügt – dies ist die öffentliche Schnittstelle für die bekannte, aber private Klasse _ConnectionFairy.

  Referenzen: #7122

• [engine] [bug] [regression]

  Behobene Regression, bei der die Methode CursorResult.fetchmany() einen serverseitigen Cursor (d. h. wenn stream_results oder yield_per verwendet wird, entweder Core- oder ORM-Ergebnisse) nicht automatisch schloss, wenn die Ergebnisse vollständig erschöpft waren.

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

  Referenzen: #7274

• [engine] [bug]

  Behobenes Problem in der zukünftigen Engine-Version, bei der das Aufrufen von Engine.begin() und das Betreten des Context-Managers die Verbindung nicht schloss, 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“ Context-Manager, die begin()-Blöcke in Core und ORM behandeln, die „BEGIN“-Operation erst ausführen, wenn die Context-Manager tatsächlich betreten werden. Dies unterscheidet sich von der Legacy-Version, die die „BEGIN“-Operation im Voraus ausführt.

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

  Referenzen: #7272

• [engine] [bug]

  Die QueuePool ignoriert nun max_overflow, wenn pool_size=0 ist, wodurch der Pool in allen Fällen ordnungsgemäß unbegrenzt wird.

  Referenzen: #8523

• [engine] [bug]

  Zur Verbesserung der Sicherheit verwendet das URL-Objekt jetzt standardmäßig Passwort-Obfuskation, wenn str(url) aufgerufen wird. Um eine URL mit Klartext-Passwort zu stringifizieren, kann die Methode URL.render_as_string() verwendet werden, wobei der Parameter URL.render_as_string.hide_password auf False gesetzt wird. Vielen Dank an unsere Mitwirkenden für diesen Pull-Request.

  Siehe auch

  str(engine.url) wird das Passwort standardmäßig obfuskieren

  Referenzen: #8567

• [engine] [bug]

  Die Methode Inspector.has_table() prüft nun konsistent auf Views mit dem angegebenen Namen sowie auf Tabellen. Zuvor war dieses Verhalten dialektabhängig, wobei PostgreSQL, MySQL/MariaDB und SQLite es unterstützten, Oracle und SQL Server jedoch nicht. Drittanbieter-Dialekte sollten ebenfalls sicherstellen, dass ihre Inspector.has_table()-Methode nach Views sowie nach Tabellen mit dem angegebenen Namen sucht.

  Referenzen: #7161

• [engine] [bug]

  Behobenes Problem in der Methode Result.columns(), bei der das Aufrufen von Result.columns() mit einem einzelnen Index in einigen Fällen, insbesondere bei ORM-Ergebnisobjekten, dazu führen konnte, dass das Result skalare Objekte anstelle von Row-Objekten liefert, so als wäre die Methode Result.scalars() aufgerufen worden. In SQLAlchemy 1.4 gibt dieses Szenario eine Warnung aus, dass sich das Verhalten in SQLAlchemy 2.0 ändern wird.

  Referenzen: #7953

• [engine] [bug]

  Das Übergeben eines DefaultGenerator-Objekts wie z. B. einer Sequence an die Methode Connection.execute() ist veraltet, da diese Methode so typisiert ist, dass sie ein CursorResult-Objekt und keinen einfachen Skalarwert zurückgibt. Die Methode Connection.scalar() sollte stattdessen verwendet werden. Diese wurde mit neuen internen Codepfaden überarbeitet, um das Aufrufen eines SELECT für Standardgenerierungsobjekte zu unterstützen, ohne über die Methode Connection.execute() zu gehen.

• [engine] [removed]

  Der zuvor veraltete Parameter case_sensitive von create_engine() wurde entfernt. Dieser hätte nur die Suche nach Spaltennamen als Strings in Core-only Ergebniszeilen beeinflusst; er hatte keine Auswirkungen auf das Verhalten des ORM. Das tatsächliche Verhalten dessen, was case_sensitive betrifft, bleibt bei seinem Standardwert True, was bedeutet, dass String-Namen, die in row._mapping nachgeschlagen werden, wie jede andere Python-Zuordnung auch fall-sensitiv übereinstimmen.

  Beachten Sie, dass der Parameter case_sensitive in keiner Weise mit dem allgemeinen Thema der Groß-/Kleinschreibung, der Anführungszeichen und der „Namensnormalisierung“ (d. h. Umwandlung für Datenbanken, die alle Großbuchstaben als nicht fall-sensitiv betrachten) für DDL-Identifikationsnamen zusammenhängt, was weiterhin ein normales Kernmerkmal von SQLAlchemy ist.

• [engine] [removed]

  Das Legacy- und veraltete Paket sqlalchemy.databases wurde entfernt. Bitte verwenden Sie stattdessen sqlalchemy.dialects.

  Referenzen: #7258

• [engine] [deprecations]

  Der Parameter create_engine.implicit_returning ist nur für die Funktion create_engine() veraltet; der Parameter bleibt auf dem Objekt Table verfügbar. Dieser Parameter wurde ursprünglich entwickelt, um die „implizite zurückgebende“ Funktion von SQLAlchemy zu aktivieren, als sie entwickelt wurde, und war standardmäßig nicht aktiviert. Im modernen Gebrauch gibt es keinen Grund, diesen Parameter zu deaktivieren, und er hat sich als verwirrend erwiesen, da er die Leistung beeinträchtigt und es für das ORM schwieriger macht, kürzlich eingefügte Server-Standardwerte abzurufen. Der Parameter bleibt auf Table verfügbar, um speziell Datenbank-Randfälle zu berücksichtigen, bei denen RETURNING nicht praktikabel ist; das einzige derzeitige Beispiel ist die Einschränkung von SQL Server, dass INSERT RETURNING nicht auf einer Tabelle verwendet werden darf, auf der INSERT-Trigger vorhanden sind.

  Referenzen: #6962

sql

• [sql] [feature]

  Die lang ersehnten fall-unabhängigen String-Operatoren ColumnOperators.icontains(), ColumnOperators.istartswith(), ColumnOperators.iendswith() wurden hinzugefügt, die fall-unabhängige LIKE-Kompositionen (bei PostgreSQL ILIKE und auf allen anderen Backends die LOWER()-Funktion) erzeugen, um die bestehenden LIKE-Kompositionsoperatoren ColumnOperators.contains(), ColumnOperators.startswith() usw. zu ergänzen. Vielen Dank an Matias Martinez Rebori für seine sorgfältige und vollständige Arbeit bei der Implementierung dieser neuen Methoden.

  Referenzen: #3482

• [sql] [feature]

  Eine neue Syntax wurde zur FromClause.c-Sammlung auf allen FromClause-Objekten hinzugefügt, die es erlaubt, Tupel von Schlüsseln an __getitem__() zu übergeben, zusammen mit der Unterstützung für das select()-Konstrukt zur direkten Verarbeitung der resultierenden Tupel-ähnlichen Sammlung, was die Syntax select(table.c['a', 'b', 'c']) ermöglicht. Die Unter-Sammlung, die zurückgegeben wird, ist selbst eine ColumnCollection, die nun ebenfalls direkt von select() und ähnlichen Konstrukten konsumiert werden kann.

  Siehe auch

  Festlegen der COLUMNS und FROM Klausel

  Referenzen: #8285

• [sql] [feature]

  Der Backend-unabhängige Datentyp Uuid wurde von den PostgreSQL-Dialekten generalisiert und ist nun ein Kern-Datentyp. Ebenso wurde UUID aus dem PostgreSQL-Dialekt migriert. Der SQL Server Datentyp UNIQUEIDENTIFIER wird ebenfalls zu einem UUID-behandelnden Datentyp. Vielen Dank an Trevor Gross für die Hilfe dabei.

  Referenzen: #7212

• [sql] [feature]

  Die Datentypen Double, DOUBLE, DOUBLE_PRECISION wurden dem Namespace des Basismoduls sqlalchemy. hinzugefügt, zur expliziten Verwendung von Double/Double Precision sowie generischen „Double“-Datentypen. Verwenden Sie Double für generische Unterstützung, die bei Bedarf für verschiedene Backends in DOUBLE/DOUBLE PRECISION/FLOAT aufgelöst wird.

  Referenzen: #5465

• [sql] [usecase]

  Die Kompilierungsmechanik des Insert-Konstrukts wurde so geändert, dass die „autoincrement primary key“-Spaltenwert über cursor.lastrowid oder RETURNING abgerufen wird, auch wenn er im Parametersatz oder innerhalb der Methode Insert.values() als einfacher gebundener Wert vorhanden ist, für einzelne Zeilen-INSERT-Anweisungen auf bestimmten Backends, die bekannt dafür sind, Autoincrement-Werte zu generieren, auch wenn explizites NULL übergeben wird. Dies stellt ein Verhalten wieder her, das in der 1.3-Serie sowohl für den Anwendungsfall eines separaten Parametersatzes als auch für Insert.values() galt. In 1.4 änderte sich das Verhalten des Parametersatzes unbeabsichtigt dahingehend, dass dies nicht mehr geschah, aber die Methode Insert.values() rief Autoincrement-Werte bis 1.4.21 ab, als #6770 das Verhalten erneut unbeabsichtigt änderte, da dieser Anwendungsfall nie abgedeckt war.

  Das Verhalten ist nun als „funktionierend“ definiert, um den Fall zu berücksichtigen, dass Datenbanken wie SQLite, MySQL und MariaDB einen expliziten NULL-Primärschlüsselwert ignorieren und dennoch einen Autoincrement-Generator aufrufen.

  Referenzen: #7998

• [sql] [usecase]

  Eine modifizierte ISO-8601-Darstellung (d. h. ISO-8601 mit T, das durch ein Leerzeichen ersetzt wird) wurde für die Verwendung von literal_binds mit den SQL-Kompilern der PostgreSQL-, MySQL-, MariaDB-, MSSQL- und Oracle-Dialekte hinzugefügt. Für Oracle wird das ISO-Format in einen entsprechenden TO_DATE()-Funktionsaufruf verpackt. Zuvor war diese Darstellung für die dialektspezifische Kompilierung nicht implementiert.

  Siehe auch

  DATE, TIME, DATETIME Datentypen unterstützen jetzt die literale Darstellung auf allen Backends

  Referenzen: #5052

• [sql] [usecase]

  Ein neuer Parameter HasCTE.add_cte.nest_here wurde zu HasCTE.add_cte() hinzugefügt, der eine gegebene CTE auf der Ebene der übergeordneten Anweisung „verschachtelt“. Dieser Parameter ist äquivalent zur Verwendung des Parameters HasCTE.cte.nesting, kann aber in manchen Szenarien intuitiver sein, da er die Verschachtelungsattribut gleichzeitig mit dem expliziten Level der CTE festlegen lässt.

  Die Methode HasCTE.add_cte() akzeptiert auch mehrere CTE-Objekte.

  Referenzen: #7759

• [sql] [bug]

  Die FROM-Klauseln, die auf einem select()-Konstrukt mit der Methode Select.select_from() erstellt werden, werden nun zuerst in der FROM-Klausel des gerenderten SELECT gerendert. Dies dient dazu, die Reihenfolge der Klauseln beizubehalten, wie sie an die Methode Select.select_from() übergeben wurden, ohne von der Tatsache beeinflusst zu werden, dass diese Klauseln auch in anderen Teilen der Abfrage erwähnt werden. Wenn andere Elemente des Select FROM-Klauseln generieren, wie z. B. die Spaltenklausel oder die WHERE-Klausel, werden diese nach den von Select.select_from() gelieferten Klauseln gerendert, sofern sie nicht explizit ebenfalls an Select.select_from() übergeben wurden. Diese Verbesserung ist nützlich in den Fällen, in denen eine bestimmte Datenbank einen wünschenswerten Abfrageplan basierend auf einer bestimmten Reihenfolge von FROM-Klauseln generiert und ermöglicht eine vollständige Kontrolle über die Reihenfolge der FROM-Klauseln.

  Referenzen: #7888

• [sql] [bug]

  Der Parameter Enum.length, der die Länge der VARCHAR-Spalte für nicht-native Enumerationstypen festlegt, wird nun bedingungslos beim Emittieren von DDL für den Datentyp VARCHAR verwendet, auch wenn der Parameter Enum.native_enum für Ziel-Backends auf True gesetzt ist, die weiterhin VARCHAR verwenden. Zuvor wurde der Parameter in diesem Fall fälschlicherweise ignoriert. Die für diesen Fall zuvor ausgegebene Warnung wurde nun entfernt.

  Referenzen: #7791

• [sql] [bug]

  Die In-Place-Typenerkennung für Python-Integer, wie sie bei einem Ausdruck wie literal(25) auftritt, wird nun auch eine wertebasierte Anpassung vornehmen, um große Python-Integer zu berücksichtigen, wobei der ermittelte Datentyp BigInteger anstelle von Integer ist. Dies berücksichtigt Dialekte wie den von asyncpg, der sowohl implizite Typinformationen an den Treiber sendet als auch empfindlich auf die numerische Skala reagiert.

  Referenzen: #7909

• [sql] [bug]

  Die Parameter if_exists und if_not_exists wurden für alle „Create“-/„Drop“-Konstrukte hinzugefügt, einschließlich CreateSequence, DropSequence, CreateIndex, DropIndex, etc., was die generische Renderung von „IF EXISTS“/„IF NOT EXISTS“-Phrasen innerhalb von DDL ermöglicht. Pull-Request freundlicherweise von Jesse Bakker.

  Referenzen: #7354

• [sql] [bug]

  Die Konstruktion von SQL binären Ausdrücken wurde verbessert, um sehr lange Ausdrücke mit demselben assoziativen Operator zu ermöglichen, ohne dass spezielle Schritte erforderlich sind, um einen hohen Speicherverbrauch und übermäßige Rekursionstiefe zu vermeiden. Eine bestimmte binäre Operation A op B kann nun gegen ein weiteres Element op C verbunden werden, und die resultierende Struktur wird „geglättet“, sodass die Darstellung sowie die SQL-Kompilierung keine Rekursion erfordern.

  Eine Auswirkung dieser Änderung ist, dass String-Verkettungsausdrücke, die SQL-Funktionen verwenden, „flach“ herauskommen, z. B. MySQL rendert nun concat('x', 'y', 'z', ...)` anstelle von zweiwertigen Funktionen wie concat(concat('x', 'y'), 'z'). Drittanbieter-Dialekte, die den String-Verkettungsoperator überschreiben, müssen eine neue Methode def visit_concat_op_expression_clauselist() implementieren, die die vorhandene Methode def visit_concat_op_binary() begleitet.

  Referenzen: #7744

• [sql] [bug]

  Vollständige Unterstützung für „truediv“ und „floordiv“ unter Verwendung der Operatoren „/“ und „//“ implementiert. Eine „truediv“-Operation zwischen zwei Ausdrücken mit Integer betrachtet das Ergebnis nun als Numeric, und die Kompilierung auf Dialektebene wandelt den rechten Operanden basierend auf dem Dialekt in einen numerischen Typ um, um sicherzustellen, dass „truediv“ erreicht wird. Für „floordiv“ wird auch eine Konvertierung für Datenbanken hinzugefügt, die „floordiv“ nicht standardmäßig unterstützen (MySQL, Oracle), und die Funktion FLOOR() wird in diesem Fall gerendert, sowie für Fälle, in denen der rechte Operand keine Ganzzahl ist (erforderlich für PostgreSQL und andere).

  Die Änderung behebt Probleme sowohl mit inkonsistentem Verhalten des Divisionsoperators auf verschiedenen Backends als auch ein Problem, bei dem die Ganzzahldivision unter Oracle aufgrund ungeeigneter Outputtypehandler kein Ergebnis abrufen konnte.

  Siehe auch

  Der Python-Divisionsoperator führt für alle Backends eine echte Division durch; Ganzzahldivision wurde hinzugefügt

  Referenzen: #4926

• [sql] [bug]

  Ein zusätzlicher Nachverfolgungsschritt wurde zum Compiler hinzugefügt, der alle FROM-Klauseln verfolgt, die Tabellen sind. Diese Tabellen können denselben Namen in mehreren Schemata teilen, wobei eines der Schemata das implizite „Standard“-Schema ist. In diesem Fall wird der Tabellenname, wenn auf diesen Namen ohne Schemaklassifizierung verwiesen wird, auf Compiler-Ebene mit einem anonymen Aliasnamen gerendert, um die beiden (oder mehr) Namen zu disambiguieren. Der Ansatz, den normalerweise nicht qualifizierten Namen mit dem vom Server erkannten Wert „Standard-Schemaname“ zu qualifizieren, wurde ebenfalls in Betracht gezogen, dieser Ansatz gilt jedoch nicht für Oracle und wird von SQL Server nicht akzeptiert, noch würde er mit mehreren Einträgen im PostgreSQL-Suchpfad funktionieren. Das hier behobene Namenskollisionsproblem wurde als Auswirkungen auf mindestens Oracle, PostgreSQL, SQL Server, MySQL und MariaDB identifiziert.

  Referenzen: #7471

• [sql] [bug]

  Python-Zeichenkettenwerte, für die ein SQL-Typ aus dem Typ des Wertes bestimmt wird, hauptsächlich bei Verwendung von literal(), wenden nun den Typ String an, anstelle des Datentyps Unicode, für Python-Zeichenkettenwerte, die mit Python str.isascii() als „nur ASCII“ getestet werden. Wenn die Zeichenkette nicht isascii() ist, wird stattdessen der Datentyp Unicode gebunden, der zuvor bei der gesamten Zeichenkettenerkennung verwendet wurde. Dieses Verhalten gilt **nur für die In-situ-Erkennung von Datentypen bei Verwendung von ``literal()`` oder anderen Kontexten, die keinen vorhandenen Datentyp haben**, was normalerweise nicht der Fall ist bei normalen Column-Vergleichsoperationen, bei denen der Typ der verglichenen Column immer Vorrang hat.

  Die Verwendung des Datentyps Unicode kann die literale Zeichenkettenformatierung auf Backends wie SQL Server bestimmen, wo ein literaler Wert (d.h. unter Verwendung von literal_binds) als N'<wert>' anstelle von 'wert' gerendert wird. Bei der normalen Behandlung gebundener Werte kann der Datentyp Unicode auch Auswirkungen auf die Übergabe von Werten an den DBAPI haben, wiederum im Fall von SQL Server unterstützt der pyodbc-Treiber die Verwendung des setinputsizes-Modus, der String im Vergleich zu Unicode unterschiedlich behandelt.

  Referenzen: #7551

• [sql] [bug]

  Die array_agg setzt nun die Array-Dimensionen auf 1. Die ARRAY-Verarbeitung wurde verbessert, um None-Werte als Werte eines Multi-Arrays zu akzeptieren.

  Referenzen: #7083

schema

• [schema] [feature]

  Das System der „bedingten DDL“, das von der Klasse ExecutableDDLElement (umbenannt von DDLElement) implementiert wurde, wurde erweitert, um direkt auf SchemaItem-Konstrukte wie Index, ForeignKeyConstraint usw. angewendet zu werden, sodass die bedingte Logik für die Generierung dieser Elemente in den Standardprozess der DDL-Ausgabe integriert ist. Dieses System kann auch von einer zukünftigen Version von Alembic übernommen werden, um bedingte DDL-Elemente in allen Schemamanagementsystemen zu unterstützen.

  Siehe auch

  Neue bedingte DDL für Constraints und Indizes

  Referenzen: #7631

• [schema] [usecase]

  Der Parameter DropConstraint.if_exists wurde dem DropConstraint-Konstrukt hinzugefügt, was zu einer „IF EXISTS“-DDL im DROP-Statement führt. Diese Phrase wird nicht von allen Datenbanken akzeptiert und die Operation schlägt auf einer Datenbank fehl, die sie nicht unterstützt, da keine ähnlich kompatible Fallback-Lösung im Geltungsbereich eines einzelnen DDL-Statements vorhanden ist. Pull Request von Mike Fiedler.

  Referenzen: #8141

• [schema] [usecase]

  Die DDL-Event-Hooks DDLEvents.before_create(), DDLEvents.after_create(), DDLEvents.before_drop(), DDLEvents.after_drop() wurden für alle SchemaItem-Objekte implementiert, die einen eindeutigen CREATE- oder DROP-Schritt beinhalten, wenn dieser Schritt als eigenständiger SQL-Befehl aufgerufen wird, einschließlich für ForeignKeyConstraint, Sequence, Index und PostgreSQLs ENUM.

  Referenzen: #8394

• [schema] [performance]

  Die Schema-Reflexions-API wurde überarbeitet, um teilnehmenden Dialekten die Nutzung von hochperformanten Batch-Abfragen zu ermöglichen, um Schemata vieler Tabellen auf einmal mit um eine Größenordnung geringeren Abfragen zu reflektieren. Die neuen Leistungsmerkmale sind zunächst auf die PostgreSQL- und Oracle-Backends ausgerichtet und können auf jeden Dialekt angewendet werden, der SELECT-Abfragen gegen Systemkatalogtabellen zur Tabellenreflexion verwendet. Die Änderung umfasst auch neue API-Funktionen und Verhaltensverbesserungen für das Inspector-Objekt, einschließlich konsistenten, gecachten Verhaltens von Methoden wie Inspector.has_table(), Inspector.get_table_names() und neuen Methoden Inspector.has_schema() und Inspector.has_index().

  Siehe auch

  Umfangreiche architektonische, Leistungs- und API-Verbesserungen für die Datenbankreflexion - vollständiger Hintergrund

  Referenzen: #4379

• [schema] [bug]

  Die Warnungen, die bei der Reflexion von Indizes oder eindeutigen Constraints ausgegeben werden, wenn der Parameter Table.include_columns verwendet wird, um Spalten auszuschließen, die dann Teil dieser Constraints sind, wurden entfernt. Wenn der Parameter Table.include_columns verwendet wird, sollte erwartet werden, dass die resultierende Table-Konstruktion keine Constraints enthält, die auf weggelassene Spalten angewiesen sind. Diese Änderung erfolgte als Reaktion auf #8100, das Table.include_columns in Verbindung mit Fremdschlüssel-Constraints, die auf weggelassene Spalten angewiesen sind, reparierte, wobei der Anwendungsfall klar wurde, dass das Weglassen solcher Constraints erwartet werden sollte.

  Referenzen: #8102

• [schema] [postgresql]

  Unterstützung für Kommentare auf Constraint-Objekten, einschließlich DDL und Reflexion, hinzugefügt; das Feld wird zur Basisklasse Constraint und den entsprechenden Konstruktoren hinzugefügt. Derzeit unterstützt jedoch nur PostgreSQL das Feature. Siehe Parameter wie ForeignKeyConstraint.comment, UniqueConstraint.comment oder CheckConstraint.comment.

  Referenzen: #5677

• [schema] [mariadb] [mysql]

  Unterstützung für Partitionierung und Sample-Seiten für MySQL und MariaDB reflektierte Optionen hinzugefügt. Die Optionen werden im Wörterbuch der Tabellen-Dialekt-Optionen gespeichert, sodass die folgenden Schlüssel mit mysql_ oder mariadb_ präfigiert werden müssen, abhängig vom Backend. Unterstützte Optionen sind

  • stats_sample_pages

  • partition_by

  • partitions

  • subpartition_by

  Diese Optionen werden auch beim Laden einer Tabelle aus der Datenbank reflektiert und füllen die Table.dialect_options der Tabelle. Pull Request von Ramon Will.

  Referenzen: #4038

typing

• [typing] [improvement]

  Die Methode TypeEngine.with_variant() gibt nun eine Kopie des ursprünglichen TypeEngine-Objekts zurück, anstatt es in die Variant-Klasse zu wrappen, die effektiv entfernt wurde (das Importsymbol bleibt aus Kompatibilitätsgründen mit Code, der möglicherweise nach diesem Symbol sucht). Während der vorherige Ansatz In-Python-Verhaltensweisen beibehielt, ermöglicht die Beibehaltung des ursprünglichen Typs eine klarere Typüberprüfung und Fehlersuche.

  TypeEngine.with_variant() akzeptiert auch mehrere Dialektnamen pro Aufruf, was insbesondere für verwandte Backend-Namen wie "mysql", "mariadb" nützlich ist.

  Siehe auch

  „with_variant()“ klont den ursprünglichen TypeEngine anstatt den Typ zu ändern

  Referenzen: #6980

postgresql

• [postgresql] [feature]

  Ein neuer PostgreSQL-Datentyp DOMAIN wurde hinzugefügt, der die gleichen CREATE TYPE / DROP TYPE-Verhaltensweisen wie PostgreSQL ENUM aufweist. Vielen Dank an David Baumgold für die Bemühungen hierzu.

  Siehe auch

  DOMAIN

  Referenzen: #7316

• [postgresql] [usecase] [asyncpg]

  Übernehmbare Methoden PGDialect_asyncpg.setup_asyncpg_json_codec und PGDialect_asyncpg.setup_asyncpg_jsonb_codec Codec wurden hinzugefügt, 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, übernehmbare Methoden aufgeteilt werden, um Drittanbieter-Dialekte zu unterstützen, die ändern oder deaktivieren müssen, wie diese speziellen Codecs eingerichtet werden.

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

  Referenzen: #7284

• [postgresql] [usecase]

  Literale Typen-Rendering für die Datentypen ARRAY und ARRAY hinzugefügt. Das generische Stringify rendert mit Klammern, z.B. [1, 2, 3] und das PostgreSQL-spezifische verwendet das ARRAY-Literal, z.B. ARRAY[1, 2, 3]. Mehrere Dimensionen und Anführungszeichen werden ebenfalls berücksichtigt.

  Referenzen: #8138

• [postgresql] [usecase]

  Fügt Unterstützung für PostgreSQL-Multirange-Typen hinzu, die in PostgreSQL 14 eingeführt wurden. Die Unterstützung für PostgreSQL-Bereiche und Multibereiche wurde nun auf die Backends psycopg3, psycopg2 und asyncpg verallgemeinert, mit Raum für weitere Dialektunterstützung, unter Verwendung eines Backend-unabhängigen Range-Datenobjekts, dessen Konstruktor mit dem zuvor verwendeten psycopg2-Objekt kompatibel ist. Siehe die neue Dokumentation für Verwendungsmuster.

  Darüber hinaus wurde die Handhabung von Bereichstypen verbessert, sodass automatisch Typumwandlungen gerendert werden, sodass In-situ-Rundreisen für Anweisungen, die der Datenbank keinen Kontext bieten, nicht den cast()-Konstrukt erfordern, damit die Datenbank den gewünschten Typ kennt (diskutiert unter #8540).

  Vielen Dank an @zeeeeeb für den Pull-Request zur Implementierung und zum Testen der neuen Datentypen und der psycopg-Unterstützung.

  Siehe auch

  Neue RANGE / MULTIRANGE-Unterstützung und Änderungen für PostgreSQL-Backends

  Range und Multirange Typen

  Referenzen: #7156, #8540

• [postgresql] [usecase]

  Die „Ping“-Abfrage, die beim Konfigurieren von create_engine.pool_pre_ping für psycopg, asyncpg und pg8000, aber nicht für psycopg2, ausgegeben wird, wurde auf eine leere Abfrage (;) anstelle von SELECT 1 geändert; zusätzlich wurde für den asyncpg-Treiber die unnötige Verwendung eines vorbereiteten Statements für diese Abfrage behoben. Begründung ist die Eliminierung der Notwendigkeit, dass PostgreSQL einen Abfrageplan erstellt, wenn der Ping ausgegeben wird. Die Operation wird derzeit nicht vom psycopg2-Treiber unterstützt, der weiterhin SELECT 1 verwendet.

  Referenzen: #8491

• [postgresql] [change]

  SQLAlchemy erfordert nun PostgreSQL-Version 9 oder höher. Ältere Versionen können in einigen begrenzten Anwendungsfällen weiterhin funktionieren.

• [postgresql] [change] [mssql]

  Der Parameter UUID.as_uuid von UUID, der zuvor spezifisch für den PostgreSQL-Dialekt war, aber nun für Core verallgemeinert wurde (zusammen mit einem neuen Backend-unabhängigen Datentyp Uuid), steht nun standardmäßig auf True, was bedeutet, dass Python UUID-Objekte von diesem Datentyp standardmäßig akzeptiert werden. Zusätzlich wurde der SQL Server UNIQUEIDENTIFIER-Datentyp zu einem UUID-empfangenden Typ konvertiert; für Legacy-Code, der UNIQUEIDENTIFIER unter Verwendung von Zeichenkettenwerten verwendet, setzen Sie den Parameter UNIQUEIDENTIFIER.as_uuid auf False.

  Referenzen: #7225

• [postgresql] [change]

  Der Parameter ENUM.name für den PostgreSQL-spezifischen Datentyp ENUM ist nun ein erforderliches Schlüsselwortargument. Der „Name“ ist in jedem Fall erforderlich, damit das ENUM als Fehler verwendet werden kann, wenn „name“ nicht vorhanden ist, was zur SQL/DDL-Renderzeit zu einem Fehler führen würde.

• [postgresql] [change]

  Zur Unterstützung neuer PostgreSQL-Funktionen, einschließlich des psycopg3-Dialekts sowie der erweiterten „fast insertmany“-Unterstützung, wurde das System, mit dem Typinformationen für gebundene Parameter an die PostgreSQL-Datenbank übergeben werden, neu gestaltet, um Inline-Casts zu verwenden, die vom SQL-Compiler ausgegeben werden, und wird nun auf alle PostgreSQL-Dialekte angewendet. Dies steht im Gegensatz zum bisherigen Ansatz, der sich auf die Verwendung des DBAPI zum Rendern dieser Casts verlassen hätte, was in Fällen wie dem von pg8000 und dem angepassten asyncpg-Treiber die pep-249 setinputsizes()-Methode verwenden würde, oder mit dem psycopg2-Treiber in den meisten Fällen auf den Treiber selbst angewiesen wäre, mit einigen Sonderfällen für ARRAY.

  Der neue Ansatz rendert nun alle PostgreSQL-Dialekte diese Casts nach Bedarf mit PostgreSQL-Doppelpunkt-Stil im Compiler, und die Verwendung von setinputsizes() wurde für PostgreSQL-Dialekte entfernt, da dies im Allgemeinen bei diesen DBAPIs ohnehin nicht Teil war (pg8000 ist die einzige Ausnahme, die die Methode auf Wunsch von SQLAlchemy-Entwicklern hinzugefügt hat).

  Vorteile dieses Ansatzes sind die Leistung pro Anweisung, da keine zweite Durchsicht der kompilierten Anweisung zur Ausführungszeit erforderlich ist, bessere Unterstützung für alle DBAPIs, da es nun ein einheitliches System zur Anwendung von Typinformationen gibt, und verbesserte Transparenz, da die SQL-Protokollausgabe sowie die Zeichenkettenausgabe einer kompilierten Anweisung diese Casts direkt in der Anweisung anzeigen, während zuvor diese Casts in der Protokollausgabe nicht sichtbar waren, da sie nach der Protokollierung der Anweisung erfolgten.

• [postgresql] [bug]

  Der Operator Operators.match() verwendet nun plainto_tsquery() für die PostgreSQL-Volltextsuche anstelle von to_tsquery(). Die Begründung für diese Änderung ist eine bessere Kreuzkompatibilität mit dem Match auf anderen Datenbank-Backends. Volle Unterstützung für alle PostgreSQL-Volltextfunktionen bleibt über die Verwendung von func in Verbindung mit Operators.bool_op() (einer verbesserten Version von Operators.op() für boolesche Operatoren) verfügbar.

  Siehe auch

  Der Operator match() unter PostgreSQL verwendet plainto_tsquery() anstelle von to_tsquery()

  Referenzen: #7086

• [postgresql] [removed]

  Unterstützung für mehrere veraltete Treiber entfernt

  • pypostgresql für PostgreSQL. Dies ist als externer Treiber unter https://github.com/PyGreSQL verfügbar

  • pygresql für PostgreSQL.

  Bitte wechseln Sie zu einem der unterstützten Treiber oder zur externen Version desselben Treibers.

  Referenzen: #7258

• [postgresql] [dialect]

  Unterstützung für den psycopg-Dialekt hinzugefügt, der sowohl synchrone als auch asynchrone Ausführung unterstützt. Dieser Dialekt ist unter dem Namen postgresql+psycopg sowohl für die create_engine()- als auch für die create_async_engine()-Funktionen zur Erzeugung von Engines verfügbar.

  Siehe auch

  Dialektunterstützung für psycopg 3 (auch bekannt als „psycopg“)

  psycopg

  Referenzen: #6842

• [postgresql] [psycopg2]

  Aktualisierung des psycopg2-Dialekts zur Verwendung der DBAPI-Schnittstelle zur Ausführung von Zweiphasentransaktionen. Zuvor wurden SQL-Befehle zur Handhabung dieser Art von Transaktionen ausgeführt.

  Referenzen: #7238

• [postgresql] [schema]

  Der Typ JSONPATH wurde eingeführt, der in Cast-Ausdrücken verwendet werden kann. Dies ist für einige PostgreSQL-Dialekte erforderlich, wenn Funktionen wie jsonb_path_exists oder jsonb_path_match verwendet werden, die einen jsonpath als Eingabe akzeptieren.

  Siehe auch

  JSON-Typen - PostgreSQL JSON-Typen.

  Referenzen: #8216

• [postgresql] [reflection]

  Der PostgreSQL-Dialekt unterstützt nun die Reflexion von ausdrucksbasierten Indizes. Die Reflexion wird sowohl bei der Verwendung von Inspector.get_indexes() als auch bei der Reflexion einer Table mittels Table.autoload_with unterstützt. Dank an immerrr und Aidan Kane für die Hilfe bei diesem Ticket.

  Referenzen: #7442

mysql

• [mysql] [usecase] [mariadb]

  Die Funktion ROLLUP rendert WITH ROLLUP nun korrekt auf MySql und MariaDB, was die Verwendung von Group By Rollup mit diesen Backends ermöglicht.

  Referenzen: #8503

• [mysql] [bug]

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

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

  Referenzen: #7281

• [mysql] [removed]

  Die Unterstützung für den OurSQL-Treiber für MySQL und MariaDB wurde entfernt, da dieser Treiber anscheinend nicht mehr gewartet wird.

  Referenzen: #7258

mariadb

• [mariadb] [usecase]

  Eine neue Ausführungsoption is_delete_using=True wurde hinzugefügt, die vom ORM beim Verwenden einer ORM-aktivierten DELETE-Anweisung in Verbindung mit der „fetch“-Synchronisierungsstrategie verbraucht wird; diese Option gibt an, dass erwartet wird, dass die DELETE-Anweisung mehrere Tabellen verwendet, was auf MariaDB die DELETE..USING-Syntax ist. Die Option gibt dann an, dass RETURNING (neu implementiert in SQLAlchemy 2.0 für MariaDB für #7011) nicht für Datenbanken verwendet werden sollte, von denen bekannt ist, dass sie keine „DELETE..USING..RETURNING“-Syntax unterstützen, auch wenn sie „DELETE..USING“ unterstützen, was die aktuelle Fähigkeit von MariaDB ist.

  Die Begründung für diese Option ist, dass die aktuellen Arbeitsweisen von ORM-aktiviertem DELETE nicht im Voraus wissen, ob eine DELETE-Anweisung für mehrere Tabellen bestimmt ist oder nicht, bis die Kompilierung erfolgt, die in jedem Fall zwischengespeichert wird, aber bekannt sein muss, damit eine SELECT für die zu löschende Zeile im Voraus ausgegeben werden kann. Anstatt eine pauschale Leistungsstrafe für alle DELETE-Anweisungen anzuwenden, indem diese alle proaktiv auf dieses relativ ungewöhnliche SQL-Muster überprüft werden, wird die Ausführungsoption is_delete_using=True über eine neue Ausnahmemeldung angefordert, die während des Kompilierungsschritts ausgelöst wird. Diese Ausnahmemeldung wird speziell (und nur) ausgelöst, wenn: die Anweisung eine ORM-aktivierte DELETE ist, bei der die „fetch“-Synchronisierungsstrategie angefordert wurde; das Backend MariaDB oder ein anderes Backend mit dieser spezifischen Einschränkung ist; die Anweisung während der ersten Kompilierung erkannt wurde, dass sie andernfalls „DELETE..USING..RETURNING“ ausgeben würde. Durch Anwenden der Ausführungsoption weiß das ORM, stattdessen eine SELECT im Voraus auszuführen. Eine ähnliche Option ist für ORM-aktivierte UPDATE implementiert, aber derzeit ist kein Backend erforderlich, bei dem sie benötigt wird.

  Referenzen: #8344

• [mariadb] [usecase]

  Unterstützung für INSERT..RETURNING und DELETE..RETURNING für das MariaDB-Dialekt hinzugefügt. UPDATE..RETURNING wird von MariaDB noch nicht unterstützt. MariaDB unterstützt INSERT..RETURNING ab 10.5.0 und DELETE..RETURNING ab 10.0.5.

  Referenzen: #7011

sqlite

• [sqlite] [usecase]

  Neuer Parameter für SQLite für Reflektionsmethoden namens sqlite_include_internal=True hinzugefügt; wenn weggelassen, werden lokale Tabellen, die mit dem Präfix sqlite_ beginnen, die laut SQLite-Dokumentation als „interne Schematabellen“ bezeichnet werden, wie z. B. die sqlite_sequence-Tabelle, die zur Unterstützung von „AUTOINCREMENT“-Spalten generiert wird, nicht in Reflektionsmethoden, die Listen lokaler Objekte zurückgeben, enthalten sein. Dies verhindert beispielsweise Probleme bei der Verwendung von Alembic Autogenerate, die diese von SQLite generierten Tabellen zuvor als aus dem Modell entfernt betrachtet hätte.

  Siehe auch

  Reflexion von Tabellen des internen Schemas

  Referenzen: #8234

• [sqlite] [usecase]

  RETURNING-Unterstützung für das SQLite-Dialekt hinzugefügt. SQLite unterstützt RETURNING seit Version 3.35.

  Referenzen: #6195

• [sqlite] [usecase] [performance]

  SQLite-Datentypen datetime, date und time verwenden nun die fromisoformat()-Methoden der Python-Standardbibliothek, um eingehende Datums- und Zeitwerte zu parsen. Dies verbessert die Leistung im Vergleich zum früheren regulären Ausdruck-basierten Ansatz und berücksichtigt automatisch Datums- und Zeitformate, die entweder ein sechsstellige „Mikrosekunden“-Format oder ein dreistellige „Millisekunden“-Format enthalten.

  Referenzen: #7029

• [sqlite] [usecase]

  Das SQLite-Dialekt unterstützt nun die UPDATE..FROM-Syntax für UPDATE-Anweisungen, die sich auf zusätzliche Tabellen im WHERE-Kriterium der Anweisung beziehen können, ohne Unterabfragen verwenden zu müssen. Diese Syntax wird automatisch aufgerufen, wenn der Update-Konstrukt verwendet wird, wenn mehr als eine Tabelle oder eine andere Entität oder wählbares Objekt verwendet wird.

  Referenzen: #7185

• [sqlite] [bug]

  Die Warnung, die vom Typ Numeric bezüglich DBAPIs, die Decimal-Werte nicht nativ unterstützen, ausgegeben wurde, wurde entfernt. Diese Warnung richtete sich an SQLite, das ohne zusätzliche Erweiterungen oder Workarounds keine Möglichkeit hat, numerische Werte mit Präzision über 15 signifikante Stellen zu verarbeiten, da es nur Fließkomma-Arithmetik zur Darstellung von Zahlen verwendet. Da dies eine bekannte und dokumentierte Einschränkung von SQLite selbst und kein Eigenart des pysqlite-Treibers ist, besteht für SQLAlchemy kein Grund, davor zu warnen. Die Änderung ändert nicht die Handhabung von numerischen Werten mit Präzision. Werte können weiterhin als Decimal() oder float() behandelt werden, wie sie mit Numeric, Float und verwandten Datentypen konfiguriert sind, jedoch ohne die Möglichkeit, bei Verwendung von SQLite Präzision über 15 signifikante Stellen hinaus aufrechtzuerhalten, es sei denn, es werden alternative Darstellungen wie Strings verwendet.

  Referenzen: #7299

• [sqlite] [bug] [performance]

  Das SQLite-Dialekt verwendet nun standardmäßig QueuePool, wenn eine dateibasierte Datenbank verwendet wird. Dies wird zusammen mit der Einstellung des Parameters check_same_thread auf False vorgenommen. Es wurde beobachtet, dass der vorherige Ansatz, standardmäßig auf NullPool zu setzen, der die Datenbankverbindungen nach der Freigabe nicht beibehält, tatsächlich messbare negative Auswirkungen auf die Leistung hatte. Wie immer ist die Pool-Klasse über den Parameter create_engine.poolclass anpassbar.

  Siehe auch

  Das SQLite-Dialekt verwendet QueuePool für dateibasierte Datenbanken

  Referenzen: #7490

mssql

• [mssql] [usecase]

  Die Reflexion des Flags „clustered index“ mssql_clustered für das SQL Server-Dialekt wurde implementiert. Pull-Request von John Lennox.

  Referenzen: #8288

• [mssql] [usecase]

  Unterstützung für Tabellen- und Spaltenkommentare unter MSSQL beim Erstellen einer Tabelle hinzugefügt. Unterstützung für die Reflexion von Tabellenkommentaren hinzugefügt. Dank an Daniel Hall für die Hilfe bei diesem Pull-Request.

  Referenzen: #7844

• [mssql] [bug]

  Der Parameter use_setinputsizes für das Dialekt mssql+pyodbc ist nun standardmäßig True; dies bewirkt, dass Nicht-Unicode-String-Vergleiche von pyodbc an pyodbc.SQL_VARCHAR und nicht an pyodbc.SQL_WVARCHAR gebunden werden, wodurch Indizes auf VARCHAR-Spalten wirksam werden können. Damit der Parameter fast_executemany=True weiterhin funktioniert, überspringt der use_setinputsizes-Modus nun den Aufruf von cursor.setinputsizes() speziell dann, wenn fast_executemany True ist und die verwendete Methode cursor.executemany() ist, die setinputsizes nicht unterstützt. Die Änderung fügt auch geeignete pyodbc DBAPI-Typisierungen für Werte hinzu, die als Unicode oder UnicodeText typisiert sind, sowie die Basis-Datentyp JSON so geändert, dass JSON-String-Werte als Unicode anstatt als String betrachtet werden.

  Referenzen: #8177

• [mssql] [removed]

  Die Unterstützung für den mxodbc-Treiber wurde aufgrund mangelnder Testunterstützung entfernt. ODBC-Benutzer können das pyodbc-Dialekt verwenden, das vollständig unterstützt wird.

  Referenzen: #7258

oracle

• [oracle] [feature]

  Unterstützung für den neuen Oracle-Treiber oracledb hinzugefügt.

  Siehe auch

  Dialektunterstützung für oracledb

  python-oracledb

  Referenzen: #8054

• [oracle] [feature]

  DDL- und Reflexionsunterstützung für FLOAT-Datentypen, die einen expliziten „binary_precision“-Wert enthalten, wurde implementiert. Unter Verwendung des Oracle-spezifischen FLOAT-Datentyps kann der neue Parameter FLOAT.binary_precision angegeben werden, der die Präzision von Oracle für Gleitkommazahlen direkt rendert. Dieser Wert wird bei der Reflexion interpretiert. Nach der Reflexion eines FLOAT-Datentyps ist der zurückgegebene Datentyp DOUBLE_PRECISION für ein FLOAT mit einer Präzision von 126 (dies ist auch die Standardpräzision von Oracle für FLOAT), REAL für eine Präzision von 63 und FLOAT für eine benutzerdefinierte Präzision, gemäß der Oracle-Dokumentation.

  Als Teil dieser Änderung wird der generische Wert Float.precision bei der Generierung von DDL für Oracle ausdrücklich abgelehnt, da diese Präzision nicht genau in „binary precision“ umgewandelt werden kann; stattdessen ermutigt eine Fehlermeldung die Verwendung von TypeEngine.with_variant(), damit die spezifische Form der Präzision von Oracle genau gewählt werden kann. Dies ist eine abwärtsinkompatible Verhaltensänderung, da der vorherige „precision“-Wert für Oracle stillschweigend ignoriert wurde.

  Siehe auch

  Neuer Oracle FLOAT-Typ mit binärer Präzision; Dezimalpräzision wird nicht direkt akzeptiert

  Referenzen: #5465

• [oracle] [feature]

  Vollständige „RETURNING“-Unterstützung wurde für das cx_Oracle-Dialekt implementiert, die zwei individuelle Arten von Funktionalität abdeckt

  • Mehrzeilige RETURNING ist implementiert, was bedeutet, dass nun mehrere RETURNING-Zeilen für DML-Anweisungen empfangen werden, die mehr als eine Zeile für RETURNING erzeugen.

  • „executemany RETURNING“ ist ebenfalls implementiert – dies ermöglicht es RETURNING, Zeilen pro Anweisung zurückzugeben, wenn cursor.executemany() verwendet wird. Die Implementierung dieses Teils der Funktion liefert dramatische Leistungsverbesserungen für ORM-Einfügungen, auf die gleiche Weise, wie sie für psycopg2 in der SQLAlchemy 1.4-Änderung ORM Batch-Einfügungen mit psycopg2 batchieren nun in den meisten Fällen Anweisungen mit RETURNING hinzugefügt wurde.

  Referenzen: #6245

• [oracle] [usecase]

  Oracle verwendet nun standardmäßig die FETCH FIRST N ROWS / OFFSET-Syntax für Limit/Offset-Unterstützung für Oracle 12c und höher. Diese Syntax war bereits verfügbar, wenn Select.fetch() direkt verwendet wurde, jetzt ist sie auch für Select.limit() und Select.offset() impliziert.

  Referenzen: #8221

• [oracle] [change]

  Materialized Views unter Oracle werden nun als Views reflektiert. In früheren Versionen von SQLAlchemy wurden die Views unter den Tabellennamen, nicht unter den View-Namen zurückgegeben. Als Nebeneffekt dieser Änderung werden sie von MetaData.reflect() nicht standardmäßig reflektiert, es sei denn, views=True ist gesetzt. Um eine Liste von Materialized Views zu erhalten, verwenden Sie die neue Inspektionsmethode Inspector.get_materialized_view_names().

• [oracle] [bug]

  Anpassungen wurden an den BLOB / CLOB / NCLOB-Datentypen in den cx_Oracle- und oracledb-Dialekten vorgenommen, um die Leistung basierend auf Empfehlungen von Oracle-Entwicklern zu verbessern.

  Referenzen: #7494

• [oracle] [bug]

  Im Zusammenhang mit der Deprecation für create_engine.implicit_returning ist die Funktion „implicit_returning“ nun in allen Fällen für das Oracle-Dialekt aktiviert; zuvor war die Funktion deaktiviert, wenn eine Oracle 8/8i-Version erkannt wurde, jedoch zeigt die Online-Dokumentation an, dass beide Versionen dieselbe RETURNING-Syntax wie moderne Versionen unterstützen.

  Referenzen: #6962

• [oracle]

  cx_Oracle 7 ist nun die Mindestversion für cx_Oracle.

misc

• [removed] [sybase]

  Das interne „sybase“-Dialekt, das in früheren SQLAlchemy-Versionen als veraltet markiert war, wurde entfernt. Unterstützung durch Drittanbieter-Dialekte ist verfügbar.

  Siehe auch

  Externe Dialekte

  Referenzen: #7258

• [removed] [firebird]

  Das interne „firebird“-Dialekt, das in früheren SQLAlchemy-Versionen als veraltet markiert war, wurde entfernt. Unterstützung durch Drittanbieter-Dialekte ist verfügbar.

  Siehe auch

  Externe Dialekte

  Referenzen: #7258