[sql] [bug] \u00b6
Fixed caching issue where the\n+
[sql] [bug] \u00b6
Fixed caching issue where using the TextualSelect.add_cte() method\n+of the TextualSelect construct would not set a correct cache key\n+which distinguished between different CTE expressions.
References: #11471
\n+\n+[sql] [bug] \u00b6
Fixed caching issue where the\n Select.with_for_update.key_share element of\n Select.with_for_update() was not considered as part of the cache\n key, leading to incorrect caching if different variations of this parameter\n were used with an otherwise identical statement.
References: #11544
\n \n[sql] [bug] \u00b6
Fixed caching issue where using the TextualSelect.add_cte() method\n-of the TextualSelect construct would not set a correct cache key\n-which distinguished between different CTE expressions.
References: #11471
\n-\n-[mypy] [bug] \u00b6
The deprecated mypy plugin is no longer fully functional with the latest\n series of mypy 1.11.0, as changes in the mypy interpreter are no longer\n", "details": [{"source1": "html2text {}", "source2": "html2text {}", "unified_diff": "@@ -808,24 +808,24 @@\n sqlalchemy.util.await_only() directly.\n [\b[e\ben\bng\bgi\bin\bne\be]\b] [\b[b\bbu\bug\bg]\b] _\b\u00b6\n Adjustments to the C extensions, which are specific to the SQLAlchemy 1.x\n series, to work under Python 3.13. Pull request courtesy Ben Beasley.\n References: _\b#_\b1_\b1_\b4_\b9_\b9\n *\b**\b**\b**\b* s\bsq\bql\bl_\b?\b\u00b6 *\b**\b**\b**\b*\n * [\b[s\bsq\bql\bl]\b] [\b[b\bbu\bug\bg]\b] _\b\u00b6\n- Fixed caching issue where the _\bS_\be_\bl_\be_\bc_\bt_\b._\bw_\bi_\bt_\bh_\b__\bf_\bo_\br_\b__\bu_\bp_\bd_\ba_\bt_\be_\b._\bk_\be_\by_\b__\bs_\bh_\ba_\br_\be element of\n- _\bS_\be_\bl_\be_\bc_\bt_\b._\bw_\bi_\bt_\bh_\b__\bf_\bo_\br_\b__\bu_\bp_\bd_\ba_\bt_\be_\b(_\b) was not considered as part of the cache key,\n- leading to incorrect caching if different variations of this parameter\n- were used with an otherwise identical statement.\n- References: _\b#_\b1_\b1_\b5_\b4_\b4\n+ Fixed caching issue where using the _\bT_\be_\bx_\bt_\bu_\ba_\bl_\bS_\be_\bl_\be_\bc_\bt_\b._\ba_\bd_\bd_\b__\bc_\bt_\be_\b(_\b) method of the\n+ _\bT_\be_\bx_\bt_\bu_\ba_\bl_\bS_\be_\bl_\be_\bc_\bt construct would not set a correct cache key which\n+ distinguished between different CTE expressions.\n+ References: _\b#_\b1_\b1_\b4_\b7_\b1\n [\b[s\bsq\bql\bl]\b] [\b[b\bbu\bug\bg]\b] _\b\u00b6\n-Fixed caching issue where using the _\bT_\be_\bx_\bt_\bu_\ba_\bl_\bS_\be_\bl_\be_\bc_\bt_\b._\ba_\bd_\bd_\b__\bc_\bt_\be_\b(_\b) method of the\n-_\bT_\be_\bx_\bt_\bu_\ba_\bl_\bS_\be_\bl_\be_\bc_\bt construct would not set a correct cache key which distinguished\n-between different CTE expressions.\n-References: _\b#_\b1_\b1_\b4_\b7_\b1\n+Fixed caching issue where the _\bS_\be_\bl_\be_\bc_\bt_\b._\bw_\bi_\bt_\bh_\b__\bf_\bo_\br_\b__\bu_\bp_\bd_\ba_\bt_\be_\b._\bk_\be_\by_\b__\bs_\bh_\ba_\br_\be element of\n+_\bS_\be_\bl_\be_\bc_\bt_\b._\bw_\bi_\bt_\bh_\b__\bf_\bo_\br_\b__\bu_\bp_\bd_\ba_\bt_\be_\b(_\b) was not considered as part of the cache key, leading\n+to incorrect caching if different variations of this parameter were used with\n+an otherwise identical statement.\n+References: _\b#_\b1_\b1_\b5_\b4_\b4\n *\b**\b**\b**\b* m\bmy\byp\bpy\by_\b?\b\u00b6 *\b**\b**\b**\b*\n * [\b[m\bmy\byp\bpy\by]\b] [\b[b\bbu\bug\bg]\b] _\b\u00b6\n The deprecated mypy plugin is no longer fully functional with the latest\n series of mypy 1.11.0, as changes in the mypy interpreter are no longer\n compatible with the approach used by the plugin. If code is dependent on\n the mypy plugin with sqlalchemy2-stubs, it\u2019s recommended to pin mypy to\n be below the 1.11.0 series. Seek upgrading to the 2.0 series of\n"}]}, {"source1": "./usr/share/doc/python-sqlalchemy-doc/html/changelog/changelog_20.html", "source2": "./usr/share/doc/python-sqlalchemy-doc/html/changelog/changelog_20.html", "unified_diff": "@@ -7935,31 +7935,31 @@\n
\n[sqlite] [usecase] \u00b6
Added RETURNING support for the SQLite dialect. SQLite supports RETURNING\n since version 3.35.
\nReferences: #6195
\n \n[sqlite] [usecase] [performance] \u00b6
SQLite datetime, date, and time datatypes now use Python standard lib\n+
[sqlite] [usecase] \u00b6
The SQLite dialect now supports UPDATE..FROM syntax, for UPDATE statements\n+that may refer to additional tables within the WHERE criteria of the\n+statement without the need to use subqueries. This syntax is invoked\n+automatically when using the Update construct when more than\n+one table or other entity or selectable is used.
References: #7185
\n+\n+[sqlite] [performance] [usecase] \u00b6
SQLite datetime, date, and time datatypes now use Python standard lib\n fromisoformat() methods in order to parse incoming datetime, date, and\n time string values. This improves performance vs. the previous regular\n expression-based approach, and also automatically accommodates for datetime\n and time formats that contain either a six-digit \u201cmicroseconds\u201d format or a\n three-digit \u201cmilliseconds\u201d format.
References: #7029
\n \n[sqlite] [usecase] \u00b6
The SQLite dialect now supports UPDATE..FROM syntax, for UPDATE statements\n-that may refer to additional tables within the WHERE criteria of the\n-statement without the need to use subqueries. This syntax is invoked\n-automatically when using the Update construct when more than\n-one table or other entity or selectable is used.
References: #7185
\n-\n-[sqlite] [bug] \u00b6
Removed the warning that emits from the Numeric type about\n DBAPIs not supporting Decimal values natively. This warning was oriented\n towards SQLite, which does not have any real way without additional\n extensions or workarounds of handling precision numeric values more than 15\n significant digits as it only uses floating point math to represent\n numbers. As this is a known and documented limitation in SQLite itself, and\n not a quirk of the pysqlite driver, there\u2019s no need for SQLAlchemy to warn\n", "details": [{"source1": "html2text {}", "source2": "html2text {}", "unified_diff": "@@ -5471,29 +5471,29 @@\n See also\n _\bR_\be_\bf_\bl_\be_\bc_\bt_\bi_\bn_\bg_\b _\bi_\bn_\bt_\be_\br_\bn_\ba_\bl_\b _\bs_\bc_\bh_\be_\bm_\ba_\b _\bt_\ba_\bb_\bl_\be_\bs\n References: _\b#_\b8_\b2_\b3_\b4\n [\b[s\bsq\bql\bli\bit\bte\be]\b] [\b[u\bus\bse\bec\bca\bas\bse\be]\b] _\b\u00b6\n Added RETURNING support for the SQLite dialect. SQLite supports RETURNING since\n version 3.35.\n References: _\b#_\b6_\b1_\b9_\b5\n-[\b[s\bsq\bql\bli\bit\bte\be]\b] [\b[u\bus\bse\bec\bca\bas\bse\be]\b] [\b[p\bpe\ber\brf\bfo\bor\brm\bma\ban\bnc\bce\be]\b] _\b\u00b6\n-SQLite datetime, date, and time datatypes now use Python standard lib\n-fromisoformat() methods in order to parse incoming datetime, date, and time\n-string values. This improves performance vs. the previous regular expression-\n-based approach, and also automatically accommodates for datetime and time\n-formats that contain either a six-digit \u201cmicroseconds\u201d format or a three-digit\n-\u201cmilliseconds\u201d format.\n-References: _\b#_\b7_\b0_\b2_\b9\n [\b[s\bsq\bql\bli\bit\bte\be]\b] [\b[u\bus\bse\bec\bca\bas\bse\be]\b] _\b\u00b6\n The SQLite dialect now supports UPDATE..FROM syntax, for UPDATE statements that\n may refer to additional tables within the WHERE criteria of the statement\n without the need to use subqueries. This syntax is invoked automatically when\n using the _\bU_\bp_\bd_\ba_\bt_\be construct when more than one table or other entity or\n selectable is used.\n References: _\b#_\b7_\b1_\b8_\b5\n+[\b[s\bsq\bql\bli\bit\bte\be]\b] [\b[p\bpe\ber\brf\bfo\bor\brm\bma\ban\bnc\bce\be]\b] [\b[u\bus\bse\bec\bca\bas\bse\be]\b] _\b\u00b6\n+SQLite datetime, date, and time datatypes now use Python standard lib\n+fromisoformat() methods in order to parse incoming datetime, date, and time\n+string values. This improves performance vs. the previous regular expression-\n+based approach, and also automatically accommodates for datetime and time\n+formats that contain either a six-digit \u201cmicroseconds\u201d format or a three-digit\n+\u201cmilliseconds\u201d format.\n+References: _\b#_\b7_\b0_\b2_\b9\n [\b[s\bsq\bql\bli\bit\bte\be]\b] [\b[b\bbu\bug\bg]\b] _\b\u00b6\n Removed the warning that emits from the _\bN_\bu_\bm_\be_\br_\bi_\bc type about DBAPIs not\n supporting Decimal values natively. This warning was oriented towards SQLite,\n which does not have any real way without additional extensions or workarounds\n of handling precision numeric values more than 15 significant digits as it only\n uses floating point math to represent numbers. As this is a known and\n documented limitation in SQLite itself, and not a quirk of the pysqlite driver,\n"}]}, {"source1": "./usr/share/doc/python-sqlalchemy-doc/html/orm/examples.html", "source2": "./usr/share/doc/python-sqlalchemy-doc/html/orm/examples.html", "comments": ["Ordering differences only"], "unified_diff": "@@ -299,49 +299,49 @@\n
Examples illustrating the usage of the \u201cassociation object\u201d pattern,\n where an intermediary class mediates the relationship between two\n classes that are associated in a many-to-many pattern.
\nListing of files:
basic_association.py - Illustrate a many-to-many relationship between an\n+\u201cOrder\u201d and a collection of \u201cItem\u201d objects, associating a purchase price\n+with each via an association object called \u201cOrderItem\u201d
\n+dict_of_sets_with_default.py - An advanced association proxy example which\n illustrates nesting of association proxies to produce multi-level Python\n collections, in this case a dictionary with string keys and sets of integers\n as values, which conceal the underlying mapped classes.
\nproxied_association.py - Same example as basic_association, adding in\n usage of sqlalchemy.ext.associationproxy to make explicit references\n to OrderItem optional.
basic_association.py - Illustrate a many-to-many relationship between an\n-\u201cOrder\u201d and a collection of \u201cItem\u201d objects, associating a purchase price\n-with each via an association object called \u201cOrderItem\u201d
\n-Examples illustrating the asyncio engine feature of SQLAlchemy.
\nListing of files:
async_orm_writeonly.py - Illustrates using write only relationships for simpler handling\n of ORM collections under asyncio.
\nasync_orm.py - Illustrates use of the sqlalchemy.ext.asyncio.AsyncSession object\n+for asynchronous ORM use.
greenlet_orm.py - Illustrates use of the sqlalchemy.ext.asyncio.AsyncSession object\n for asynchronous ORM use, including the optional run_sync() method.
\nbasic.py - Illustrates the asyncio engine / connection interface.
\n+gather_orm_statements.py - Illustrates how to run many statements concurrently using asyncio.gather()\n along many asyncio database connections, merging ORM results into a single\n AsyncSession.
basic.py - Illustrates the asyncio engine / connection interface.
\n-async_orm.py - Illustrates use of the sqlalchemy.ext.asyncio.AsyncSession object\n-for asynchronous ORM use.
An example of persistence for a directed graph structure. The\n graph is stored as a collection of edges, each referencing both a\n@@ -378,32 +378,32 @@\n subclassing the HasAddresses mixin, which ensures that the\n parent class is provided with an addresses collection\n which contains Address objects.
The discriminator_on_association.py and generic_fk.py scripts\n are modernized versions of recipes presented in the 2007 blog post\n Polymorphic Associations with SQLAlchemy.
\nListing of files:
discriminator_on_association.py - Illustrates a mixin which provides a generic association\n+using a single target table and a single association table,\n+referred to by all parent tables. The association table\n+contains a \u201cdiscriminator\u201d column which determines what type of\n+parent object associates to each particular row in the association\n+table.
\n+table_per_related.py - Illustrates a generic association which persists association\n objects within individual tables, each one generated to persist\n those objects on behalf of a particular parent class.
\ngeneric_fk.py - Illustrates a so-called \u201cgeneric foreign key\u201d, in a similar fashion\n to that of popular frameworks such as Django, ROR, etc. This\n approach bypasses standard referential integrity\n practices, in that the \u201cforeign key\u201d column is not actually\n constrained to refer to any particular table; instead,\n in-application logic is used to determine which table is referenced.
\ndiscriminator_on_association.py - Illustrates a mixin which provides a generic association\n-using a single target table and a single association table,\n-referred to by all parent tables. The association table\n-contains a \u201cdiscriminator\u201d column which determines what type of\n-parent object associates to each particular row in the association\n-table.
\n-table_per_association.py - Illustrates a mixin which provides a generic association\n via a individually generated association tables for each parent class.\n The associated objects themselves are persisted in a single table\n shared among all parents.
\nSee also
\n \nListing of files:
large_resultsets.py - In this series of tests, we are looking at time to load a large number\n-of very small and simple rows.
\n-bulk_inserts.py - This series of tests illustrates different ways to INSERT a large number\n-of rows in bulk.
\n+single_inserts.py - In this series of tests, we\u2019re looking at a method that inserts a row\n+within a distinct transaction, and afterwards returns to essentially a\n+\u201cclosed\u201d state. This would be analogous to an API call that starts up\n+a database connection, inserts the row, commits and closes.
\nshort_selects.py - This series of tests illustrates different ways to SELECT a single\n record by primary key
\n__main__.py - Allows the examples/performance package to be run as a script.
\nsingle_inserts.py - In this series of tests, we\u2019re looking at a method that inserts a row\n-within a distinct transaction, and afterwards returns to essentially a\n-\u201cclosed\u201d state. This would be analogous to an API call that starts up\n-a database connection, inserts the row, commits and closes.
\n+bulk_inserts.py - This series of tests illustrates different ways to INSERT a large number\n+of rows in bulk.
\n+large_resultsets.py - In this series of tests, we are looking at time to load a large number\n+of very small and simple rows.
\nbulk_updates.py - This series of tests will illustrate different ways to UPDATE a large number\n of rows in bulk (under construction! there\u2019s just one test at the moment)
\nSeveral examples that illustrate the technique of intercepting changes\n that would be first interpreted as an UPDATE on a row, and instead turning\n it into an INSERT of a new row, leaving the previous row intact as\n a historical version.
\nCompare to the Versioning with a History Table example which writes a\n history row to a separate history table.
\nListing of files:
versioned_map.py - A variant of the versioned_rows example built around the\n-concept of a \u201cvertical table\u201d structure, like those illustrated in\n-Vertical Attribute Mapping examples.
\n-versioned_rows.py - Illustrates a method to intercept changes on objects, turning\n-an UPDATE statement on a single row into an INSERT statement, so that a new\n-row is inserted with the new data, keeping the old row intact.
\n-versioned_update_old_row.py - Illustrates the same UPDATE into INSERT technique of versioned_rows.py,\n but also emits an UPDATE on the old row to affect a change in timestamp.\n Also includes a SessionEvents.do_orm_execute() hook to limit queries\n to only the most recent version.
versioned_rows_w_versionid.py - Illustrates a method to intercept changes on objects, turning\n an UPDATE statement on a single row into an INSERT statement, so that a new\n row is inserted with the new data, keeping the old row intact.
\nversioned_map.py - A variant of the versioned_rows example built around the\n+concept of a \u201cvertical table\u201d structure, like those illustrated in\n+Vertical Attribute Mapping examples.
\n+versioned_rows.py - Illustrates a method to intercept changes on objects, turning\n+an UPDATE statement on a single row into an INSERT statement, so that a new\n+row is inserted with the new data, keeping the old row intact.
\n+Illustrates \u201cvertical table\u201d mappings.
\n@@ -800,35 +800,35 @@\n q = (session.query(Animal).\n filter(Animal.facts.any(\n and_(AnimalFact.key == u'weasel-like',\n AnimalFact.value == True))))\n print('weasel-like animals', q.all())\n \nListing of files:
dictlike-polymorphic.py - Mapping a polymorphic-valued vertical table as a dictionary.
\n-dictlike.py - Mapping a vertical table as a dictionary.
\ndictlike-polymorphic.py - Mapping a polymorphic-valued vertical table as a dictionary.
\n+Working examples of single-table, joined-table, and concrete-table\n inheritance as described in Mapping Class Inheritance Hierarchies.
\nListing of files:
concrete.py - Concrete-table (table-per-class) inheritance example.
\nsingle.py - Single-table (table-per-hierarchy) inheritance example.
\n-joined.py - Joined-table (table-per-subclass) inheritance example.
\nsingle.py - Single-table (table-per-hierarchy) inheritance example.
\n+