-"""Illustrates how to place a dictionary-like facade on top of a "dynamic" relation, so
-that dictionary operations (assuming simple string keys) can operate upon a large
-collection without loading the full collection at once.
+""" Illustrates how to place a dictionary-like facade on top of a
+"dynamic" relation, so that dictionary operations (assuming simple
+string keys) can operate upon a large collection without loading the
+full collection at once.
"""
\ No newline at end of file
In order of complexity:
-* ``pickle.py`` - Quick and dirty, serialize the whole DOM into a BLOB column. While the example
- is very brief, it has very limited functionality.
-* ``adjacency_list.py`` - Each DOM node is stored in an individual table row, with attributes
- represented in a separate table. The nodes are associated in a hierarchy using an adjacency list
- structure. A query function is introduced which can search for nodes along any path with a given
- structure of attributes, basically a (very narrow) subset of xpath.
-* ``optimized_al.py`` - Uses the same strategy as ``adjacency_list.py``, but associates each
- DOM row with its owning document row, so that a full document of DOM nodes can be
- loaded using O(1) queries - the construction of the "hierarchy" is performed after
- the load in a non-recursive fashion and is much more efficient.
+* ``pickle.py`` - Quick and dirty, serialize the whole DOM into a BLOB
+ column. While the example is very brief, it has very limited
+ functionality.
+
+* ``adjacency_list.py`` - Each DOM node is stored in an individual
+ table row, with attributes represented in a separate table. The
+ nodes are associated in a hierarchy using an adjacency list
+ structure. A query function is introduced which can search for nodes
+ along any path with a given structure of attributes, basically a
+ (very narrow) subset of xpath.
+
+* ``optimized_al.py`` - Uses the same strategy as
+ ``adjacency_list.py``, but associates each DOM row with its owning
+ document row, so that a full document of DOM nodes can be loaded
+ using O(1) queries - the construction of the "hierarchy" is performed
+ after the load in a non-recursive fashion and is much more
+ efficient.
E.g.::
The ``discriminator_on_association.py`` script in particular is a modernized
version of the "polymorphic associations" example present in older versions of
-SQLAlchemy, originally from the blog post at http://techspot.zzzeek.org/2007/05/29/polymorphic-associations-with-sqlalchemy/.
+SQLAlchemy, originally from the blog post at
+http://techspot.zzzeek.org/2007/05/29/polymorphic-associations-with-sqlalchemy/.
"""
\ No newline at end of file
-"""
-An example of persistence for a directed graph structure. The graph is stored as a collection of edges, each referencing both a "lower" and an "upper" node in a table of nodes. Basic persistence and querying for lower- and upper- neighbors are illustrated::
+"""An example of persistence for a directed graph structure. The
+graph is stored as a collection of edges, each referencing both a
+"lower" and an "upper" node in a table of nodes. Basic persistence
+and querying for lower- and upper- neighbors are illustrated::
n2 = Node(2)
n5 = Node(5)
-"""
-Working examples of single-table, joined-table, and concrete-table inheritance as described in :ref:`datamapping_inheritance`.
+"""Working examples of single-table, joined-table, and concrete-table
+inheritance as described in :ref:`datamapping_inheritance`.
"""
\ No newline at end of file
"""Large collection example.
-Illustrates the options to use with :func:`~sqlalchemy.orm.relationship()` when the list of related objects is very large, including:
+Illustrates the options to use with
+:func:`~sqlalchemy.orm.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 greatly improve the performance of related collection deletion.
+* how to use ON DELETE CASCADE in conjunction with
+ ``passive_deletes=True`` to greatly improve the performance of
+ related collection deletion.
"""
-"""
-Illustrates a rudimentary way to implement the "nested sets" pattern for hierarchical data using the SQLAlchemy ORM.
+""" Illustrates a rudimentary way to implement the "nested sets"
+pattern for hierarchical data using the SQLAlchemy ORM.
"""
\ No newline at end of file
"""A naive example illustrating techniques to help
embed PostGIS functionality.
-This example was originally developed in the hopes that it would be extrapolated into a comprehensive PostGIS integration layer. We are pleased to announce that this has come to fruition as `GeoAlchemy <http://www.geoalchemy.org/>`_.
+This example was originally developed in the hopes that it would be
+extrapolated into a comprehensive PostGIS integration layer. We are
+pleased to announce that this has come to fruition as `GeoAlchemy
+<http://www.geoalchemy.org/>`_.
The example illustrates:
all() \\
== [SomeClassHistory(version=1, name='sc1')]
-The ``Versioned`` mixin is designed to work with declarative. To use the extension with
-classical mappers, the ``_history_mapper`` function can be applied::
+The ``Versioned`` mixin is designed to work with declarative. To use
+the extension with classical mappers, the ``_history_mapper`` function
+can be applied::
from history_meta import _history_mapper
"""
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/document management systems in order to represent user-created structures flexibly.
-
-Two variants on the approach are given. In the second, each row references a "datatype" which contains information about the type of information stored in the attribute, such as integer, string, or date.
+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/document management systems in order
+to represent user-created structures flexibly.
+
+Two variants on the approach are given. In the second, each row
+references a "datatype" which contains information about the type of
+information stored in the attribute, such as integer, string, or date.
Example::
projects / thirdparty / sqlalchemy / sqlalchemy.git / commitdiff
