See also
\n \nReferences: #4710
\n \n \n-[engine] [performance] \u00b6
The pool \u201cpre-ping\u201d feature has been refined to not invoke for a DBAPI\n-connection that was just opened in the same checkout operation. pre ping\n-only applies to a DBAPI connection that\u2019s been checked into the pool\n-and is being checked out again.
\n-References: #4524
\n-\n-[engine] [performance] [change] [py3k] \u00b6
Disabled the \u201cunicode returns\u201d check that runs on dialect startup when\n+
[engine] [change] [performance] [py3k] \u00b6
Disabled the \u201cunicode returns\u201d check that runs on dialect startup when\n running under Python 3, which for many years has occurred in order to test\n the current DBAPI\u2019s behavior for whether or not it returns Python Unicode\n or Py2K strings for the VARCHAR and NVARCHAR datatypes. The check still\n occurs by default under Python 2, however the mechanism to test the\n behavior will be removed in SQLAlchemy 2.0 when Python 2 support is also\n removed.
\nThis logic was very effective when it was needed, however now that Python 3\n@@ -9054,14 +9047,21 @@\n dialect flags by setting the dialect level flag returns_unicode_strings\n to one of String.RETURNS_CONDITIONAL or\n String.RETURNS_BYTES, both of which will enable Unicode conversion\n even under Python 3.
References: #5315
\n \n[engine] [performance] \u00b6
The pool \u201cpre-ping\u201d feature has been refined to not invoke for a DBAPI\n+connection that was just opened in the same checkout operation. pre ping\n+only applies to a DBAPI connection that\u2019s been checked into the pool\n+and is being checked out again.
\n+References: #4524
\n+\n+[engine] [bug] \u00b6
Revised the 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. Listing 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\u201dConnection.execution_options.schema_translate_map\n feature such that the processing of the SQL statement to receive a specific\n schema name occurs within the execution phase of the statement, rather than\n at the compile phase. This is to support the statement being efficiently\n cached. Previously, the current schema being rendered into the statement\n for a particular run would be considered as part of the cache key itself,\n meaning that for a run against hundreds of schemas, there would be hundreds\n", "details": [{"source1": "html2text {}", "source2": "html2text {}", "unified_diff": "@@ -6223,21 +6223,15 @@\n returned by the ResultProxy is now the _\bL_\be_\bg_\ba_\bc_\by_\bR_\bo_\bw subclass, which maintains\n mapping/tuple hybrid behavior, however the base _\bR_\bo_\bw class now behaves more\n fully like a named tuple.\n See also\n _\bR_\bo_\bw_\bP_\br_\bo_\bx_\by_\b _\bi_\bs_\b _\bn_\bo_\b _\bl_\bo_\bn_\bg_\be_\br_\b _\ba_\b _\b\u201c_\bp_\br_\bo_\bx_\by_\b\u201d_\b;_\b _\bi_\bs_\b _\bn_\bo_\bw_\b _\bc_\ba_\bl_\bl_\be_\bd_\b _\bR_\bo_\bw_\b _\ba_\bn_\bd_\b _\bb_\be_\bh_\ba_\bv_\be_\bs_\b _\bl_\bi_\bk_\be_\b _\ba_\bn_\b _\be_\bn_\bh_\ba_\bn_\bc_\be_\bd\n _\bn_\ba_\bm_\be_\bd_\b _\bt_\bu_\bp_\bl_\be\n References: _\b#_\b4_\b7_\b1_\b0\n-[\b[e\ben\bng\bgi\bin\bne\be]\b] [\b[p\bpe\ber\brf\bfo\bor\brm\bma\ban\bnc\bce\be]\b] _\b\u00b6\n-The pool \u201cpre-ping\u201d feature has been refined to not invoke for a DBAPI\n-connection that was just opened in the same checkout operation. pre ping only\n-applies to a DBAPI connection that\u2019s been checked into the pool and is being\n-checked out again.\n-References: _\b#_\b4_\b5_\b2_\b4\n-[\b[e\ben\bng\bgi\bin\bne\be]\b] [\b[p\bpe\ber\brf\bfo\bor\brm\bma\ban\bnc\bce\be]\b] [\b[c\bch\bha\ban\bng\bge\be]\b] [\b[p\bpy\by3\b3k\bk]\b] _\b\u00b6\n+[\b[e\ben\bng\bgi\bin\bne\be]\b] [\b[c\bch\bha\ban\bng\bge\be]\b] [\b[p\bpe\ber\brf\bfo\bor\brm\bma\ban\bnc\bce\be]\b] [\b[p\bpy\by3\b3k\bk]\b] _\b\u00b6\n Disabled the \u201cunicode returns\u201d check that runs on dialect startup when running\n under Python 3, which for many years has occurred in order to test the current\n DBAPI\u2019s behavior for whether or not it returns Python Unicode or Py2K strings\n for the VARCHAR and NVARCHAR datatypes. The check still occurs by default under\n Python 2, however the mechanism to test the behavior will be removed in\n SQLAlchemy 2.0 when Python 2 support is also removed.\n This logic was very effective when it was needed, however now that Python 3 is\n@@ -6245,14 +6239,20 @@\n datatypes. In the unlikely case that a third party DBAPI does not support this,\n the conversion logic within _\bS_\bt_\br_\bi_\bn_\bg is still available and the third party\n dialect may specify this in its upfront dialect flags by setting the dialect\n level flag returns_unicode_strings to one of _\bS_\bt_\br_\bi_\bn_\bg_\b._\bR_\bE_\bT_\bU_\bR_\bN_\bS_\b__\bC_\bO_\bN_\bD_\bI_\bT_\bI_\bO_\bN_\bA_\bL or\n _\bS_\bt_\br_\bi_\bn_\bg_\b._\bR_\bE_\bT_\bU_\bR_\bN_\bS_\b__\bB_\bY_\bT_\bE_\bS, both of which will enable Unicode conversion even under\n Python 3.\n References: _\b#_\b5_\b3_\b1_\b5\n+[\b[e\ben\bng\bgi\bin\bne\be]\b] [\b[p\bpe\ber\brf\bfo\bor\brm\bma\ban\bnc\bce\be]\b] _\b\u00b6\n+The pool \u201cpre-ping\u201d feature has been refined to not invoke for a DBAPI\n+connection that was just opened in the same checkout operation. pre ping only\n+applies to a DBAPI connection that\u2019s been checked into the pool and is being\n+checked out again.\n+References: _\b#_\b4_\b5_\b2_\b4\n [\b[e\ben\bng\bgi\bin\bne\be]\b] [\b[b\bbu\bug\bg]\b] _\b\u00b6\n Revised the _\bC_\bo_\bn_\bn_\be_\bc_\bt_\bi_\bo_\bn_\b._\be_\bx_\be_\bc_\bu_\bt_\bi_\bo_\bn_\b__\bo_\bp_\bt_\bi_\bo_\bn_\bs_\b._\bs_\bc_\bh_\be_\bm_\ba_\b__\bt_\br_\ba_\bn_\bs_\bl_\ba_\bt_\be_\b__\bm_\ba_\bp feature such that\n the processing of the SQL statement to receive a specific schema name occurs\n within the execution phase of the statement, rather than at the compile phase.\n This is to support the statement being efficiently cached. Previously, the\n current schema being rendered into the statement for a particular run would be\n considered as part of the cache key itself, meaning that for a run against\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": "@@ -308,46 +308,46 @@\n \n Associations\u00b6
\n \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.py - Illustrates use of the sqlalchemy.ext.asyncio.AsyncSession object\n-for asynchronous ORM use.
\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.
greenlet_orm.py - Illustrates use of the sqlalchemy.ext.asyncio.AsyncSession object\n-for asynchronous ORM use, including the optional run_sync() method.
\n+async_orm.py - Illustrates use of the sqlalchemy.ext.asyncio.AsyncSession object\n+for asynchronous ORM use.
\nbasic.py - Illustrates the asyncio engine / connection interface.
\ngreenlet_orm.py - Illustrates use of the sqlalchemy.ext.asyncio.AsyncSession object\n+for asynchronous ORM use, including the optional run_sync() method.
\n+An example of persistence for a directed graph structure. The\n graph is stored as a collection of edges, each referencing both a\n@@ -388,32 +388,32 @@\n are modernized versions of recipes presented in the 2007 blog post\n Polymorphic Associations with SQLAlchemy.
\nListing of files:
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.
\ntable_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.
\n+generic_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.
\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.
\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.
\nLarge collection example.
\n@@ -503,30 +503,30 @@\n \nListing of files:
bulk_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)
\nlarge_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-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.
\nbulk_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.
\n+__main__.py - Allows the examples/performance package to be run as a script.
\nshort_selects.py - This series of tests illustrates different ways to SELECT a single\n record by primary key
\nbulk_inserts.py - This series of tests illustrates different ways to INSERT a large number\n-of rows in bulk.
\n-This is the default form of run:
\n$ python -m examples.performance single_inserts\n@@ -668,22 +668,22 @@\n \n \n Relationship Join Conditions\u00b6
\n Examples of various relationship() configurations,\n which make use of the primaryjoin argument to compose special types\n of join conditions.
\n Listing of files:
\n-cast.py - Illustrate a relationship() that joins two columns where those\n-columns are not of the same type, and a CAST must be used on the SQL\n-side in order to match them.
\n-threeway.py - Illustrate a \u201cthree way join\u201d - where a primary table joins to a remote\n table via an association table, but then the primary table also needs\n to refer to some columns in the remote table directly.
\n cast.py - Illustrate a relationship() that joins two columns where those\n+columns are not of the same type, and a CAST must be used on the SQL\n+side in order to match them.
\n+
\n \n \n \n Space Invaders\u00b6
\n A Space Invaders game using SQLite as the state machine.
\n Originally developed in 2012. Adapted to work in Python 3.
\n@@ -838,23 +838,23 @@\n concept of a \u201cvertical table\u201d structure, like those illustrated in\n Vertical Attribute Mapping examples.\n \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_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.
\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.
\n 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.
\n- \n \n \n Vertical Attribute Mapping\u00b6
\n Illustrates \u201cvertical table\u201d mappings.
\n@@ -879,57 +879,57 @@\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()) Listing of files:
dictlike.py - Mapping a vertical table as a dictionary.
\n-dictlike-polymorphic.py - Mapping a polymorphic-valued vertical table as a dictionary.
\ndictlike.py - Mapping a 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:
single.py - Single-table (table-per-hierarchy) inheritance example.
\n+concrete.py - Concrete-table (table-per-class) inheritance example.
\njoined.py - Joined-table (table-per-subclass) inheritance example.
\nsingle.py - Single-table (table-per-hierarchy) inheritance example.
\n-Examples illustrating modifications to SQLAlchemy\u2019s attribute management\n system.
\nListing of files:
custom_management.py - Illustrates customized class instrumentation, using\n-the sqlalchemy.ext.instrumentation extension package.
active_column_defaults.py - Illustrates use of the AttributeEvents.init_scalar()\n event, in conjunction with Core column defaults to provide\n ORM objects that automatically produce the default value\n when an un-set attribute is accessed.
listen_for_events.py - Illustrates how to attach events to all instrumented attributes\n and listen for change events.
\ncustom_management.py - Illustrates customized class instrumentation, using\n+the sqlalchemy.ext.instrumentation extension package.
A basic example of using the SQLAlchemy Sharding API.\n Sharding refers to horizontally scaling data across multiple\n@@ -958,21 +958,21 @@\n
The construction of generic sharding routines is an ambitious approach\n to the issue of organizing instances among multiple databases. For a\n more plain-spoken alternative, the \u201cdistinct entity\u201d approach\n is a simple method of assigning objects to different tables (and potentially\n database nodes) in an explicit way - described on the wiki at\n EntityName.
\nListing of files:
separate_databases.py - Illustrates sharding using distinct SQLite databases.
\n+separate_tables.py - Illustrates sharding using a single SQLite database, that will however\n+have multiple tables using a naming convention.
\nseparate_schema_translates.py - Illustrates sharding using a single database with multiple schemas,\n where a different \u201cschema_translates_map\u201d can be used for each shard.
\nseparate_tables.py - Illustrates sharding using a single SQLite database, that will however\n-have multiple tables using a naming convention.
\n+separate_databases.py - Illustrates sharding using distinct SQLite databases.
\n