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.
│ │ │ │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”
│ │ │ │ +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.
│ │ │ │ -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.
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.
│ │ │ │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 │ │ │ │ graph is stored as a collection of edges, each referencing both a │ │ │ │ @@ -388,32 +388,32 @@ │ │ │ │ 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.
│ │ │ │ +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.
│ │ │ │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.
│ │ │ │Large collection example.
│ │ │ │ @@ -503,30 +503,30 @@ │ │ │ │ │ │ │ │Listing of files:
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)
│ │ │ │large_resultsets.py - In this series of tests, we are looking at time to load a large number │ │ │ │ -of very small and simple rows.
│ │ │ │ -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.
│ │ │ │ +__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
│ │ │ │bulk_inserts.py - This series of tests illustrates different ways to INSERT a large number │ │ │ │ -of rows in bulk.
│ │ │ │ -This is the default form of run:
│ │ │ │$ python -m examples.performance single_inserts
│ │ │ │ @@ -668,22 +668,22 @@
│ │ │ │
│ │ │ │
│ │ │ │ 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:
│ │ │ │ -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.
│ │ │ │ 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.
│ │ │ │ +
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │ Space Invaders¶
│ │ │ │ A Space Invaders game using SQLite as the state machine.
│ │ │ │ Originally developed in 2012. Adapted to work in Python 3.
│ │ │ │ @@ -838,23 +838,23 @@
│ │ │ │ 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.
│ │ │ │ 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.
│ │ │ │ -
│ │ │ │
│ │ │ │
│ │ │ │ Vertical Attribute Mapping¶
│ │ │ │ Illustrates “vertical table” mappings.
│ │ │ │ @@ -879,57 +879,57 @@
│ │ │ │ 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:
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.
│ │ │ │single.py - Single-table (table-per-hierarchy) inheritance example.
│ │ │ │ -Examples illustrating modifications to SQLAlchemy’s attribute management │ │ │ │ system.
│ │ │ │Listing of files:
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.
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.
A basic example of using the SQLAlchemy Sharding API. │ │ │ │ Sharding refers to horizontally scaling data across multiple │ │ │ │ @@ -958,21 +958,21 @@ │ │ │ │
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_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_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.
│ │ │ │