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”
│ │ │ +proxied_association.py - Same example as basic_association, adding in
│ │ │ usage of sqlalchemy.ext.associationproxy to make explicit references
│ │ │ to OrderItem optional.
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”
│ │ │ -An example of persistence for a directed graph structure. The
│ │ │ graph is stored as a collection of edges, each referencing both a
│ │ │ @@ -272,18 +272,14 @@
│ │ │ 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.
│ │ │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 │ │ │ @@ -295,14 +291,18 @@ │ │ │
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.
│ │ │ +Large collection example.
│ │ │Illustrates the options to use with │ │ │ @@ -389,25 +389,25 @@ │ │ │
See also
│ │ │ │ │ │Listing of files:
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.
│ │ │short_selects.py - This series of tests illustrates different ways to SELECT a single │ │ │ record by primary key
│ │ │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 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.
│ │ │__main__.py - Allows the examples/performance package to be run as a script.
│ │ │ @@ -719,31 +719,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_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_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_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.
│ │ │ -Illustrates “vertical table” mappings.
│ │ │ @@ -783,37 +783,37 @@ │ │ │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.
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.