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:
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:
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.
│ │ │ │async_orm.py - Illustrates use of the sqlalchemy.ext.asyncio.AsyncSession object │ │ │ │ +for asynchronous ORM use.
│ │ │ │ +basic.py - Illustrates the asyncio engine / connection interface.
│ │ │ │gather_orm_statements.py - Illustrates how to run many statements concurrently using asyncio.gather()
│ │ │ │ along many asyncio database connections, merging ORM results into a single
│ │ │ │ AsyncSession.
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_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.
│ │ │ │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.
│ │ │ │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.
│ │ │ │ @@ -501,23 +501,23 @@ │ │ │ │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.
│ │ │ │ +__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
│ │ │ │__main__.py - Allows the examples/performance package to be run as a script.
│ │ │ │ +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.
│ │ │ │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.
│ │ │ │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.
│ │ │ │ @@ -831,31 +831,31 @@ │ │ │ │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 SessionEvents.do_orm_execute() hook to limit queries
│ │ │ │ -to only the most recent version.
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_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.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_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 SessionEvents.do_orm_execute() hook to limit queries
│ │ │ │ +to only the most recent version.
Illustrates “vertical table” mappings.
│ │ │ │ @@ -880,54 +880,54 @@ │ │ │ │ q = (session.query(Animal). │ │ │ │ filter(Animal.facts.any( │ │ │ │ and_(AnimalFact.key == u'weasel-like', │ │ │ │ AnimalFact.value == True)))) │ │ │ │ print('weasel-like animals', q.all()) │ │ │ │ │ │ │ │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:
concrete.py - Concrete-table (table-per-class) inheritance example.
│ │ │ │joined.py - Joined-table (table-per-subclass) inheritance example.
│ │ │ │ -single.py - Single-table (table-per-hierarchy) inheritance example.
│ │ │ │joined.py - Joined-table (table-per-subclass) 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.
│ │ │ │ -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.
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.
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_schema_translates.py - Illustrates sharding using a single database with multiple schemas, │ │ │ │ -where a different “schema_translates_map” can be used for each shard.
│ │ │ │ +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.
│ │ │ │ +separate_schema_translates.py - Illustrates sharding using a single database with multiple schemas, │ │ │ │ +where a different “schema_translates_map” can be used for each shard.
│ │ │ │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 │ │ │ │ ├── html2text {} │ │ │ │ │ @@ -123,32 +123,33 @@ │ │ │ │ │ * adjacency_list.py │ │ │ │ │ │ │ │ │ │ **** Associations¶ **** │ │ │ │ │ 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: │ │ │ │ │ - * 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. │ │ │ │ │ + * 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. │ │ │ │ │ │ │ │ │ │ **** Asyncio Integration¶ **** │ │ │ │ │ Examples illustrating the asyncio engine feature of SQLAlchemy. │ │ │ │ │ Listing of files: │ │ │ │ │ - * 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. │ │ │ │ │ + * 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. │ │ │ │ │ gather_orm_statements.py - Illustrates how to run many statements concurrently │ │ │ │ │ using asyncio.gather() along many asyncio database connections, merging ORM │ │ │ │ │ results into a single AsyncSession. │ │ │ │ │ │ │ │ │ │ **** Directed Graphs¶ **** │ │ │ │ │ An example of persistence for a directed graph structure. The graph is stored │ │ │ │ │ @@ -182,26 +183,26 @@ │ │ │ │ │ with_SQLAlchemy. │ │ │ │ │ Listing of files: │ │ │ │ │ * 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_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. │ │ │ │ │ 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. │ │ │ │ │ -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 Collections¶ **** │ │ │ │ │ Large collection example. │ │ │ │ │ Illustrates the options to use with relationship() when the list of related │ │ │ │ │ objects is very large, including: │ │ │ │ │ * “dynamic” relationships which query slices of data as accessed │ │ │ │ │ * how to use ON DELETE CASCADE in conjunction with passive_deletes=True to │ │ │ │ │ @@ -262,22 +263,22 @@ │ │ │ │ │ $ python -m examples.performance bulk_inserts \ │ │ │ │ │ --dburl mysql+mysqldb://scott:tiger@localhost/test \ │ │ │ │ │ --profile --num 1000 │ │ │ │ │ See also │ │ │ │ │ How_can_I_profile_a_SQLAlchemy_powered_application? │ │ │ │ │ *** File Listing¶ *** │ │ │ │ │ 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. │ │ │ │ │ + * __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 │ │ │ │ │ -__main__.py - Allows the examples/performance package to be run as a script. │ │ │ │ │ +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. │ │ │ │ │ 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. │ │ │ │ │ bulk_updates.py - This series of tests will illustrate different ways to UPDATE │ │ │ │ │ a large number of rows in bulk (under construction! there’s just one test at │ │ │ │ │ the moment) │ │ │ │ │ @@ -425,20 +426,20 @@ │ │ │ │ │ test_subqueryload : load everything, subquery eager loading. (1000 iterations); │ │ │ │ │ total time 2.977696 sec │ │ │ │ │ │ │ │ │ │ **** Relationship Join Conditions¶ **** │ │ │ │ │ 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. │ │ │ │ │ + * 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. │ │ │ │ │ │ │ │ │ │ **** Space Invaders¶ **** │ │ │ │ │ A Space Invaders game using SQLite as the state machine. │ │ │ │ │ Originally developed in 2012. Adapted to work in Python 3. │ │ │ │ │ Runs in a textual console using ASCII art. │ │ │ │ │ [orm/space_invaders.jpg] │ │ │ │ │ To run: │ │ │ │ │ @@ -556,28 +557,27 @@ │ │ │ │ │ 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 │ │ │ │ │ - SessionEvents.do_orm_execute() hook to limit queries to only the most │ │ │ │ │ - recent version. │ │ │ │ │ -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_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_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.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_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_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 SessionEvents.do_orm_execute() hook to │ │ │ │ │ +limit queries to only the most recent version. │ │ │ │ │ │ │ │ │ │ **** Vertical Attribute Mapping¶ **** │ │ │ │ │ Illustrates “vertical table” mappings. │ │ │ │ │ A “vertical table” refers to a technique where individual attributes of an │ │ │ │ │ object are stored as distinct rows in a table. The “vertical table” technique │ │ │ │ │ is used to persist objects which can have a varied set of attributes, at the │ │ │ │ │ expense of simple query control and brevity. It is commonly found in content/ │ │ │ │ │ @@ -597,37 +597,38 @@ │ │ │ │ │ │ │ │ │ │ q = (session.query(Animal). │ │ │ │ │ filter(Animal.facts.any( │ │ │ │ │ and_(AnimalFact.key == u'weasel-like', │ │ │ │ │ AnimalFact.value == True)))) │ │ │ │ │ print('weasel-like animals', q.all()) │ │ │ │ │ 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-polymorphic.py - Mapping a polymorphic-valued vertical table as │ │ │ │ │ + a dictionary. │ │ │ │ │ +dictlike.py - Mapping a vertical table as a dictionary. │ │ │ │ │ │ │ │ │ │ ***** Inheritance Mapping Recipes¶ ***** │ │ │ │ │ **** Basic Inheritance Mappings¶ **** │ │ │ │ │ Working examples of single-table, joined-table, and concrete-table inheritance │ │ │ │ │ as described in Mapping_Class_Inheritance_Hierarchies. │ │ │ │ │ Listing of files: │ │ │ │ │ * concrete.py - Concrete-table (table-per-class) inheritance example. │ │ │ │ │ -joined.py - Joined-table (table-per-subclass) inheritance example. │ │ │ │ │ single.py - Single-table (table-per-hierarchy) inheritance example. │ │ │ │ │ +joined.py - Joined-table (table-per-subclass) inheritance example. │ │ │ │ │ │ │ │ │ │ ***** Special APIs¶ ***** │ │ │ │ │ **** Attribute Instrumentation¶ **** │ │ │ │ │ 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. │ │ │ │ │ -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. │ │ │ │ │ + * 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. │ │ │ │ │ +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. │ │ │ │ │ │ │ │ │ │ **** Horizontal Sharding¶ **** │ │ │ │ │ A basic example of using the SQLAlchemy Sharding API. Sharding refers to │ │ │ │ │ horizontally scaling data across multiple databases. │ │ │ │ │ The basic components of a “sharded” mapping are: │ │ │ │ │ @@ -651,35 +652,36 @@ │ │ │ │ │ attempt to determine a single shard being requested. │ │ │ │ │ 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_schema_translates.py - Illustrates sharding using a single │ │ │ │ │ - database with multiple schemas, where a different “schema_translates_map” │ │ │ │ │ - can be used for each shard. │ │ │ │ │ + * 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. │ │ │ │ │ +separate_schema_translates.py - Illustrates sharding using a single database │ │ │ │ │ +with multiple schemas, where a different “schema_translates_map” can be used │ │ │ │ │ +for each shard. │ │ │ │ │ │ │ │ │ │ ***** Extending the ORM¶ ***** │ │ │ │ │ **** ORM Query Events¶ **** │ │ │ │ │ Recipes which illustrate augmentation of ORM SELECT behavior as used by │ │ │ │ │ Session.execute() with 2.0_style use of select(), as well as the 1.x_style │ │ │ │ │ Query object. │ │ │ │ │ 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: │ │ │ │ │ - * 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. │ │ │ │ │ + * 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. │ │ │ │ │ │ │ │ │ │ **** Dogpile Caching¶ **** │ │ │ │ │ Illustrates how to embed dogpile.cache functionality with ORM queries, allowing │ │ │ │ │ full cache control as well as the ability to pull “lazy loaded” attributes from │ │ │ │ │ long term cache. │ │ │ │ │ In this demo, the following techniques are illustrated: │ │ │ │ │ * Using the SessionEvents.do_orm_execute() event hook │ │ │ ├── ./usr/share/doc/python-sqlalchemy-doc/html/searchindex.js │ │ │ │ ├── js-beautify {} │ │ │ │ │ @@ -12439,17 +12439,17 @@ │ │ │ │ │ "n5": 98, │ │ │ │ │ "add_neighbor": 98, │ │ │ │ │ "higher_neighbor": 98, │ │ │ │ │ "directed_graph": 98, │ │ │ │ │ "supplier": 98, │ │ │ │ │ "hasaddress": 98, │ │ │ │ │ "generic_fk": 98, │ │ │ │ │ - "table_per_rel": 98, │ │ │ │ │ - "ror": 98, │ │ │ │ │ "table_per_associ": 98, │ │ │ │ │ + "ror": 98, │ │ │ │ │ + "table_per_rel": 98, │ │ │ │ │ "materialized_path": 98, │ │ │ │ │ "nested_set": 98, │ │ │ │ │ "single_insert": 98, │ │ │ │ │ "bulk_upd": 98, │ │ │ │ │ "test_orm_commit": 98, │ │ │ │ │ "test_bulk_insert_dictionari": 98, │ │ │ │ │ "test_cor": 98, │ │ │ │ │ @@ -12504,34 +12504,34 @@ │ │ │ │ │ "sc1": 98, │ │ │ │ │ "sc1modifi": 98, │ │ │ │ │ "someclasshistori": 98, │ │ │ │ │ "__history_mapper__": 98, │ │ │ │ │ "_history_mapp": 98, │ │ │ │ │ "somehistoryclass": 98, │ │ │ │ │ "use_mapper_vers": 98, │ │ │ │ │ - "versioned_update_old_row": 98, │ │ │ │ │ - "versioned_rows_w_versionid": 98, │ │ │ │ │ "versioned_map": 98, │ │ │ │ │ + "versioned_rows_w_versionid": 98, │ │ │ │ │ + "versioned_update_old_row": 98, │ │ │ │ │ "breviti": 98, │ │ │ │ │ "shrew": 98, │ │ │ │ │ "anim": 98, │ │ │ │ │ "cute": 98, │ │ │ │ │ "weasel": 98, │ │ │ │ │ "poison": 98, │ │ │ │ │ "animalfact": 98, │ │ │ │ │ "custom_manag": 98, │ │ │ │ │ "weather": 98, │ │ │ │ │ "contin": 98, │ │ │ │ │ "spoken": 98, │ │ │ │ │ + "separate_databas": 98, │ │ │ │ │ + "separate_t": 98, │ │ │ │ │ "separate_schema_transl": 98, │ │ │ │ │ "schema_translates_map": 98, │ │ │ │ │ - "separate_t": 98, │ │ │ │ │ - "separate_databas": 98, │ │ │ │ │ - "temporal_rang": 98, │ │ │ │ │ "filter_publ": 98, │ │ │ │ │ + "temporal_rang": 98, │ │ │ │ │ "demo": 98, │ │ │ │ │ "datafil": 98, │ │ │ │ │ "helloworld": 98, │ │ │ │ │ "local_session_cach": 98, │ │ │ │ │ "datamodel": 98, │ │ │ │ │ "postalcod": 98, │ │ │ │ │ "citi": [98, 124, 133],