[oracle] [performance] [bug] [py2k] ¶
Fixed performance regression caused by the fix for #3937 where │ │ │ +
[oracle] [bug] [performance] [py2k] ¶
Fixed performance regression caused by the fix for #3937 where
│ │ │ cx_Oracle as of version 5.3 dropped the .UNICODE symbol from its
│ │ │ namespace, which was interpreted as cx_Oracle’s “WITH_UNICODE” mode being
│ │ │ turned on unconditionally, which invokes functions on the SQLAlchemy
│ │ │ side which convert all strings to unicode unconditionally and causing
│ │ │ a performance impact. In fact, per cx_Oracle’s author the
│ │ │ “WITH_UNICODE” mode has been removed entirely as of 5.1, so the expensive unicode
│ │ │ conversion functions are no longer necessary and are disabled if
│ │ ├── ./usr/share/doc/python-sqlalchemy-doc/html/changelog/changelog_11.html
│ │ │ @@ -669,15 +669,15 @@
│ │ │
[oracle] [performance] [bug] [py2k] ¶
Fixed performance regression caused by the fix for #3937 where │ │ │ +
[oracle] [bug] [performance] [py2k] ¶
Fixed performance regression caused by the fix for #3937 where
│ │ │ cx_Oracle as of version 5.3 dropped the .UNICODE symbol from its
│ │ │ namespace, which was interpreted as cx_Oracle’s “WITH_UNICODE” mode being
│ │ │ turned on unconditionally, which invokes functions on the SQLAlchemy
│ │ │ side which convert all strings to unicode unconditionally and causing
│ │ │ a performance impact. In fact, per cx_Oracle’s author the
│ │ │ “WITH_UNICODE” mode has been removed entirely as of 5.1, so the expensive unicode
│ │ │ conversion functions are no longer necessary and are disabled if
│ │ ├── ./usr/share/doc/python-sqlalchemy-doc/html/changelog/changelog_12.html
│ │ │ @@ -2726,15 +2726,15 @@
│ │ │
[oracle] [performance] [bug] [py2k] ¶
Fixed performance regression caused by the fix for #3937 where │ │ │ +
[oracle] [bug] [performance] [py2k] ¶
Fixed performance regression caused by the fix for #3937 where
│ │ │ cx_Oracle as of version 5.3 dropped the .UNICODE symbol from its
│ │ │ namespace, which was interpreted as cx_Oracle’s “WITH_UNICODE” mode being
│ │ │ turned on unconditionally, which invokes functions on the SQLAlchemy
│ │ │ side which convert all strings to unicode unconditionally and causing
│ │ │ a performance impact. In fact, per cx_Oracle’s author the
│ │ │ “WITH_UNICODE” mode has been removed entirely as of 5.1, so the expensive unicode
│ │ │ conversion functions are no longer necessary and are disabled if
│ │ ├── ./usr/share/doc/python-sqlalchemy-doc/html/changelog/changelog_13.html
│ │ │ @@ -1471,30 +1471,30 @@
│ │ │
[oracle] [performance] [bug] ¶
Changed the implementation of fetching CLOB and BLOB objects to use │ │ │ +
[oracle] [bug] ¶
Some modifications to how the cx_oracle dialect sets up per-column │ │ │ +outputtype handlers for LOB and numeric datatypes to adjust for potential │ │ │ +changes coming in cx_Oracle 8.
│ │ │ +References: #5246
│ │ │ + │ │ │ +[oracle] [bug] [performance] ¶
Changed the implementation of fetching CLOB and BLOB objects to use │ │ │ cx_Oracle’s native implementation which fetches CLOB/BLOB objects inline │ │ │ with other result columns, rather than performing a separate fetch. As │ │ │ always, this can be disabled by setting auto_convert_lobs to False.
│ │ │As part of this change, the behavior of a CLOB that was given a blank │ │ │ string on INSERT now returns None on SELECT, which is now consistent with │ │ │ that of VARCHAR on Oracle.
│ │ │References: #5314
│ │ │ │ │ │[oracle] [bug] ¶
Some modifications to how the cx_oracle dialect sets up per-column │ │ │ -outputtype handlers for LOB and numeric datatypes to adjust for potential │ │ │ -changes coming in cx_Oracle 8.
│ │ │ -References: #5246
│ │ │ - │ │ │ -[firebird] [change] ¶
Adjusted dialect loading for firebird:// URIs so the external
│ │ │ sqlalchemy-firebird dialect will be used if it has been installed,
│ │ │ @@ -1867,15 +1867,15 @@
│ │ │
[usecase] [ext] ¶
Added keyword arguments to the MutableList.sort() function so that a
│ │ │ key function as well as the “reverse” keyword argument can be provided.
References: #5114
│ │ │ │ │ │[performance] [bug] ¶
Revised an internal change to the test system added as a result of │ │ │ +
[bug] [performance] ¶
Revised an internal change to the test system added as a result of │ │ │ #5085 where a testing-related module per dialect would be loaded │ │ │ unconditionally upon making use of that dialect, pulling in SQLAlchemy’s │ │ │ testing framework as well as the ORM into the module import space. This │ │ │ would only impact initial startup time and memory to a modest extent, │ │ │ however it’s best that these additional modules aren’t reverse-dependent on │ │ │ straight Core usage.
│ │ │References: #5180
│ │ ├── ./usr/share/doc/python-sqlalchemy-doc/html/changelog/changelog_14.html │ │ │ @@ -1107,24 +1107,15 @@ │ │ │[orm] [performance] [bug] [regression] ¶
Fixed regression involving how the ORM would resolve a given mapped column │ │ │ -to a result row, where under cases such as joined eager loading, a slightly │ │ │ -more expensive “fallback” could take place to set up this resolution due to │ │ │ -some logic that was removed since 1.3. The issue could also cause │ │ │ -deprecation warnings involving column resolution to be emitted when using a │ │ │ -1.4 style query with joined eager loading.
│ │ │ -References: #6596
│ │ │ - │ │ │ -[orm] [bug] ¶
Clarified the current purpose of the │ │ │ +
[orm] [bug] ¶
Clarified the current purpose of the
│ │ │ relationship.bake_queries flag, which in 1.4 is to enable
│ │ │ or disable “lambda caching” of statements within the “lazyload” and
│ │ │ “selectinload” loader strategies; this is separate from the more
│ │ │ foundational SQL query cache that is used for most statements.
│ │ │ Additionally, the lazy loader no longer uses its own cache for many-to-one
│ │ │ SQL queries, which was an implementation quirk that doesn’t exist for any
│ │ │ other loader scenario. Finally, the “lru cache” warning that the lazyloader
│ │ │ @@ -1134,29 +1125,38 @@
│ │ │ setting bake_queries=False for such a relationship will remove this
│ │ │ cache from being used, there’s no particular performance gain in this case
│ │ │ as using no caching vs. using a cache that needs to refresh often likely
│ │ │ still wins out on the caching being used side.
[orm] [bug] [regression] ¶
Adjusted the means by which classes such as scoped_session
│ │ │ +
[orm] [bug] [regression] ¶
Adjusted the means by which classes such as scoped_session
│ │ │ and AsyncSession are generated from the base
│ │ │ Session class, such that custom Session
│ │ │ subclasses such as that used by Flask-SQLAlchemy don’t need to implement
│ │ │ positional arguments when they call into the superclass method, and can
│ │ │ continue using the same argument styles as in previous releases.
References: #6285
│ │ │ │ │ │[orm] [bug] [regression] ¶
Fixed issue where query production for joinedload against a complex left │ │ │ +
[orm] [bug] [regression] ¶
Fixed issue where query production for joinedload against a complex left │ │ │ hand side involving joined-table inheritance could fail to produce a │ │ │ correct query, due to a clause adaption issue.
│ │ │References: #6595
│ │ │ │ │ │[orm] [bug] [performance] [regression] ¶
Fixed regression involving how the ORM would resolve a given mapped column │ │ │ +to a result row, where under cases such as joined eager loading, a slightly │ │ │ +more expensive “fallback” could take place to set up this resolution due to │ │ │ +some logic that was removed since 1.3. The issue could also cause │ │ │ +deprecation warnings involving column resolution to be emitted when using a │ │ │ +1.4 style query with joined eager loading.
│ │ │ +References: #6596
│ │ │ + │ │ │ +[orm] [bug] ¶
Fixed issue in experimental “select ORM objects from INSERT/UPDATE” use │ │ │ case where an error was raised if the statement were against a │ │ │ single-table-inheritance subclass.
│ │ │References: #6591
│ │ │ │ │ │[orm] [bug] ¶
The warning that’s emitted for relationship() when multiple
│ │ │ @@ -2000,15 +2000,15 @@
│ │ │ synonyms can be established linking to these constructs which work
│ │ │ fully. This is a behavior that was semi-explicitly disallowed previously,
│ │ │ however since it did not fail in every scenario, explicit support
│ │ │ for assoc proxy and hybrids has been added.
References: #6267
│ │ │ │ │ │[orm] [performance] [bug] [regression] [sql] ¶
Fixed a critical performance issue where the traversal of a │ │ │ +
[orm] [bug] [performance] [regression] [sql] ¶
Fixed a critical performance issue where the traversal of a
│ │ │ select() construct would traverse a repetitive product of the
│ │ │ represented FROM clauses as they were each referred towards by columns in
│ │ │ the columns clause; for a series of nested subqueries with lots of columns
│ │ │ this could cause a large delay and significant memory growth. This
│ │ │ traversal is used by a wide variety of SQL and ORM functions, including by
│ │ │ the ORM Session when it’s configured to have
│ │ │ “table-per-bind”, which while this is not a common use case, it seems to be
│ │ │ @@ -4796,15 +4796,22 @@
│ │ │
See also
│ │ │RowProxy is no longer a “proxy”; is now called Row and behaves like an enhanced named tuple
│ │ │References: #4710
│ │ │ │ │ │[engine] [change] [performance] [py3k] ¶
Disabled the “unicode returns” check that runs on dialect startup when │ │ │ +
[engine] [performance] ¶
The pool “pre-ping” feature has been refined to not invoke for a DBAPI │ │ │ +connection that was just opened in the same checkout operation. pre ping │ │ │ +only applies to a DBAPI connection that’s been checked into the pool │ │ │ +and is being checked out again.
│ │ │ +References: #4524
│ │ │ + │ │ │ +[engine] [performance] [change] [py3k] ¶
Disabled the “unicode returns” check that runs on dialect startup when │ │ │ running under Python 3, which for many years has occurred in order to test │ │ │ the current DBAPI’s behavior for whether or not it returns Python Unicode │ │ │ or Py2K strings for the VARCHAR and NVARCHAR datatypes. The check still │ │ │ occurs by default under Python 2, however the mechanism to test the │ │ │ behavior will be removed in SQLAlchemy 2.0 when Python 2 support is also │ │ │ removed.
│ │ │This logic was very effective when it was needed, however now that Python 3
│ │ │ @@ -4815,21 +4822,14 @@
│ │ │ dialect flags by setting the dialect level flag returns_unicode_strings
│ │ │ to one of String.RETURNS_CONDITIONAL or
│ │ │ String.RETURNS_BYTES, both of which will enable Unicode conversion
│ │ │ even under Python 3.
References: #5315
│ │ │ │ │ │[engine] [performance] ¶
The pool “pre-ping” feature has been refined to not invoke for a DBAPI │ │ │ -connection that was just opened in the same checkout operation. pre ping │ │ │ -only applies to a DBAPI connection that’s been checked into the pool │ │ │ -and is being checked out again.
│ │ │ -References: #4524
│ │ │ - │ │ │ -[engine] [bug] ¶
Revised the Connection.execution_options.schema_translate_map
│ │ │ feature such that the processing of the SQL statement to receive a specific
│ │ │ schema name occurs within the execution phase of the statement, rather than
│ │ │ at the compile phase. This is to support the statement being efficiently
│ │ │ cached. Previously, the current schema being rendered into the statement
│ │ │ for a particular run would be considered as part of the cache key itself,
│ │ │ meaning that for a run against hundreds of schemas, there would be hundreds
│ │ ├── ./usr/share/doc/python-sqlalchemy-doc/html/orm/examples.html
│ │ │┄ Ordering differences only
│ │ │ @@ -219,41 +219,41 @@
│ │ │
Examples illustrating the usage of the “association object” pattern, │ │ │ where an intermediary class mediates the relationship between two │ │ │ classes that are associated in a many-to-many pattern.
│ │ │Listing of files:
proxied_association.py - Same example as basic_association, adding in
│ │ │ -usage of sqlalchemy.ext.associationproxy to make explicit references
│ │ │ -to OrderItem optional.
basic_association.py - Illustrate a many-to-many relationship between an │ │ │ +“Order” and a collection of “Item” objects, associating a purchase price │ │ │ +with each via an association object called “OrderItem”
│ │ │dict_of_sets_with_default.py - An advanced association proxy example which │ │ │ illustrates nesting of association proxies to produce multi-level Python │ │ │ collections, in this case a dictionary with string keys and sets of integers │ │ │ as values, which conceal the underlying mapped classes.
│ │ │basic_association.py - Illustrate a many-to-many relationship between an │ │ │ -“Order” and a collection of “Item” objects, associating a purchase price │ │ │ -with each via an association object called “OrderItem”
│ │ │ +proxied_association.py - Same example as basic_association, adding in
│ │ │ +usage of sqlalchemy.ext.associationproxy to make explicit references
│ │ │ +to OrderItem optional.
Examples illustrating the asyncio engine feature of SQLAlchemy.
│ │ │Listing of files:
greenlet_orm.py - Illustrates use of the sqlalchemy.ext.asyncio.AsyncSession object │ │ │ -for asynchronous ORM use, including the optional run_sync() method.
│ │ │ +async_orm.py - Illustrates use of the sqlalchemy.ext.asyncio.AsyncSession object │ │ │ +for asynchronous ORM use.
│ │ │basic.py - Illustrates the asyncio engine / connection interface.
│ │ │async_orm.py - Illustrates use of the sqlalchemy.ext.asyncio.AsyncSession object │ │ │ -for asynchronous ORM use.
│ │ │ +greenlet_orm.py - Illustrates use of the sqlalchemy.ext.asyncio.AsyncSession object │ │ │ +for asynchronous ORM use, including the optional run_sync() method.
│ │ │An example of persistence for a directed graph structure. The
│ │ │ @@ -291,36 +291,36 @@
│ │ │ subclassing the HasAddresses mixin, which ensures that the
│ │ │ parent class is provided with an addresses collection
│ │ │ which contains Address objects.
The discriminator_on_association.py and generic_fk.py scripts │ │ │ are modernized versions of recipes presented in the 2007 blog post │ │ │ Polymorphic Associations with SQLAlchemy.
│ │ │Listing of files:
table_per_related.py - Illustrates a generic association which persists association │ │ │ -objects within individual tables, each one generated to persist │ │ │ -those objects on behalf of a particular parent class.
│ │ │ -table_per_association.py - Illustrates a mixin which provides a generic association │ │ │ -via a individually generated association tables for each parent class. │ │ │ -The associated objects themselves are persisted in a single table │ │ │ -shared among all parents.
│ │ │ +discriminator_on_association.py - Illustrates a mixin which provides a generic association │ │ │ +using a single target table and a single association table, │ │ │ +referred to by all parent tables. The association table │ │ │ +contains a “discriminator” column which determines what type of │ │ │ +parent object associates to each particular row in the association │ │ │ +table.
│ │ │generic_fk.py - Illustrates a so-called “generic foreign key”, in a similar fashion │ │ │ to that of popular frameworks such as Django, ROR, etc. This │ │ │ approach bypasses standard referential integrity │ │ │ practices, in that the “foreign key” column is not actually │ │ │ constrained to refer to any particular table; instead, │ │ │ in-application logic is used to determine which table is referenced.
│ │ │discriminator_on_association.py - Illustrates a mixin which provides a generic association │ │ │ -using a single target table and a single association table, │ │ │ -referred to by all parent tables. The association table │ │ │ -contains a “discriminator” column which determines what type of │ │ │ -parent object associates to each particular row in the association │ │ │ -table.
│ │ │ +table_per_association.py - Illustrates a mixin which provides a generic association │ │ │ +via a individually generated association tables for each parent class. │ │ │ +The associated objects themselves are persisted in a single table │ │ │ +shared among all parents.
│ │ │ +table_per_related.py - Illustrates a generic association which persists association │ │ │ +objects within individual tables, each one generated to persist │ │ │ +those objects on behalf of a particular parent class.
│ │ │Large collection example.
│ │ │ @@ -407,32 +407,32 @@ │ │ │See also
│ │ │ │ │ │Listing of files:
single_inserts.py - In this series of tests, we’re looking at a method that inserts a row │ │ │ -within a distinct transaction, and afterwards returns to essentially a │ │ │ -“closed” state. This would be analogous to an API call that starts up │ │ │ -a database connection, inserts the row, commits and closes.
│ │ │ -short_selects.py - This series of tests illustrates different ways to SELECT a single │ │ │ -record by primary key
│ │ │ +__main__.py - Allows the examples/performance package to be run as a script.
│ │ │large_resultsets.py - In this series of tests, we are looking at time to load a large number │ │ │ -of very small and simple rows.
│ │ │ +bulk_inserts.py - This series of tests illustrates different ways to INSERT a large number │ │ │ +of rows in bulk.
│ │ │bulk_updates.py - This series of tests illustrates different ways to UPDATE a large number │ │ │ of rows in bulk.
│ │ │bulk_inserts.py - This series of tests illustrates different ways to INSERT a large number │ │ │ -of rows in bulk.
│ │ │ +large_resultsets.py - In this series of tests, we are looking at time to load a large number │ │ │ +of very small and simple rows.
│ │ │__main__.py - Allows the examples/performance package to be run as a script.
│ │ │ +short_selects.py - This series of tests illustrates different ways to SELECT a single │ │ │ +record by primary key
│ │ │ +single_inserts.py - In this series of tests, we’re looking at a method that inserts a row │ │ │ +within a distinct transaction, and afterwards returns to essentially a │ │ │ +“closed” state. This would be analogous to an API call that starts up │ │ │ +a database connection, inserts the row, commits and closes.
│ │ │This is the default form of run:
│ │ │ @@ -575,22 +575,22 @@ │ │ │Examples of various relationship() configurations,
│ │ │ which make use of the primaryjoin argument to compose special types
│ │ │ of join conditions.
Listing of files:
threeway.py - Illustrate a “three way join” - where a primary table joins to a remote │ │ │ -table via an association table, but then the primary table also needs │ │ │ -to refer to some columns in the remote table directly.
│ │ │ -cast.py - Illustrate a relationship() that joins two columns where those
│ │ │ columns are not of the same type, and a CAST must be used on the SQL
│ │ │ side in order to match them.
threeway.py - Illustrate a “three way join” - where a primary table joins to a remote │ │ │ +table via an association table, but then the primary table also needs │ │ │ +to refer to some columns in the remote table directly.
│ │ │ +A Space Invaders game using SQLite as the state machine.
│ │ │Originally developed in 2012. Adapted to work in Python 3.
│ │ │ @@ -720,47 +720,47 @@ │ │ │ assert type(other) is SomeClass and other.id == self.idAbove, if two instance of SomeClass with the same version identifier
│ │ │ are updated and sent to the database for UPDATE concurrently, if the database
│ │ │ isolation level allows the two UPDATE statements to proceed, one will fail
│ │ │ because it no longer is against the last known version identifier.
Listing of files:
history_meta.py - Versioned mixin class and other utilities.
│ │ │ +test_versioning.py - Unit tests illustrating usage of the history_meta.py
│ │ │ module functions.
history_meta.py - Versioned mixin class and other utilities.
│ │ │ -Several examples that illustrate the technique of intercepting changes │ │ │ that would be first interpreted as an UPDATE on a row, and instead turning │ │ │ it into an INSERT of a new row, leaving the previous row intact as │ │ │ a historical version.
│ │ │Compare to the Versioning with a History Table example which writes a │ │ │ history row to a separate history table.
│ │ │Listing of files:
versioned_update_old_row.py - Illustrates the same UPDATE into INSERT technique of versioned_rows.py,
│ │ │ -but also emits an UPDATE on the old row to affect a change in timestamp.
│ │ │ -Also includes a QueryEvents.before_compile() hook to limit queries
│ │ │ -to only the most recent version.
versioned_map.py - A variant of the versioned_rows example built around the │ │ │ +concept of a “vertical table” structure, like those illustrated in │ │ │ +Vertical Attribute Mapping examples.
│ │ │versioned_rows_w_versionid.py - Illustrates a method to intercept changes on objects, turning │ │ │ +
versioned_rows.py - Illustrates a method to intercept changes on objects, turning │ │ │ an UPDATE statement on a single row into an INSERT statement, so that a new │ │ │ row is inserted with the new data, keeping the old row intact.
│ │ │versioned_rows.py - Illustrates a method to intercept changes on objects, turning │ │ │ +
versioned_rows_w_versionid.py - Illustrates a method to intercept changes on objects, turning │ │ │ an UPDATE statement on a single row into an INSERT statement, so that a new │ │ │ row is inserted with the new data, keeping the old row intact.
│ │ │versioned_map.py - A variant of the versioned_rows example built around the │ │ │ -concept of a “vertical table” structure, like those illustrated in │ │ │ -Vertical Attribute Mapping examples.
│ │ │ +versioned_update_old_row.py - Illustrates the same UPDATE into INSERT technique of versioned_rows.py,
│ │ │ +but also emits an UPDATE on the old row to affect a change in timestamp.
│ │ │ +Also includes a QueryEvents.before_compile() hook to limit queries
│ │ │ +to only the most recent version.
Listing of files:
dictlike.py - Mapping a vertical table as a dictionary.
│ │ │ -dictlike-polymorphic.py - Mapping a polymorphic-valued vertical table as a dictionary.
│ │ │dictlike.py - Mapping a vertical table as a dictionary.
│ │ │ +Working examples of single-table, joined-table, and concrete-table │ │ │ inheritance as described in Mapping Class Inheritance Hierarchies.
│ │ │Listing of files:
single.py - Single-table (table-per-hierarchy) inheritance example.
│ │ │ +concrete.py - Concrete-table (table-per-class) inheritance example.
│ │ │joined.py - Joined-table (table-per-subclass) inheritance example.
│ │ │concrete.py - Concrete-table (table-per-class) inheritance example.
│ │ │ +single.py - Single-table (table-per-hierarchy) inheritance example.
│ │ │Examples illustrating modifications to SQLAlchemy’s attribute management │ │ │ system.
│ │ │Listing of files:
listen_for_events.py - Illustrates how to attach events to all instrumented attributes │ │ │ -and listen for change events.
│ │ │ -custom_management.py - Illustrates customized class instrumentation, using
│ │ │ -the sqlalchemy.ext.instrumentation extension package.
active_column_defaults.py - Illustrates use of the AttributeEvents.init_scalar()
│ │ │ event, in conjunction with Core column defaults to provide
│ │ │ ORM objects that automatically produce the default value
│ │ │ when an un-set attribute is accessed.
custom_management.py - Illustrates customized class instrumentation, using
│ │ │ +the sqlalchemy.ext.instrumentation extension package.
listen_for_events.py - Illustrates how to attach events to all instrumented attributes │ │ │ +and listen for change events.
│ │ │ +A basic example of using the SQLAlchemy Sharding API. │ │ │ Sharding refers to horizontally scaling data across multiple │ │ │ @@ -865,19 +865,19 @@ │ │ │
The construction of generic sharding routines is an ambitious approach │ │ │ to the issue of organizing instances among multiple databases. For a │ │ │ more plain-spoken alternative, the “distinct entity” approach │ │ │ is a simple method of assigning objects to different tables (and potentially │ │ │ database nodes) in an explicit way - described on the wiki at │ │ │ EntityName.
│ │ │Listing of files:
separate_databases.py - Illustrates sharding using distinct SQLite databases.
│ │ │ +separate_tables.py - Illustrates sharding using a single SQLite database, that will however │ │ │ have multiple tables using a naming convention.
│ │ │separate_databases.py - Illustrates sharding using distinct SQLite databases.
│ │ │ -Examples include demonstrations of the with_loader_criteria()
│ │ │ option as well as the SessionEvents.do_orm_execute() hook.
As of SQLAlchemy 1.4, the Query construct is unified
│ │ │ with the Select construct, so that these two objects
│ │ │ are mostly the same.
Listing of files:
filter_public.py - Illustrates a global criteria applied to entities of a particular type.
│ │ │ +temporal_range.py - Illustrates a custom per-query criteria that will be applied │ │ │ to selected entities.
│ │ │filter_public.py - Illustrates a global criteria applied to entities of a particular type.
│ │ │ -Illustrates how to embed │ │ │ dogpile.cache