From: Mike Bayer Date: Fri, 8 Jun 2012 19:59:54 +0000 (-0400) Subject: Add some `Sphinx` related version informations paragraph-level markups, X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=ce7aab4530168820cbac6b84f8fb01c8d72776e6;p=thirdparty%2Fsqlalchemy%2Fsqlalchemy.git Add some `Sphinx` related version informations paragraph-level markups, such as ``.. versionaddedd::``, ``.. versionchanged::`` and ``.. deprecated::``. --- diff --git a/doc/build/core/interfaces.rst b/doc/build/core/interfaces.rst index 71dd8c1220..c1f4f7e829 100644 --- a/doc/build/core/interfaces.rst +++ b/doc/build/core/interfaces.rst @@ -10,8 +10,9 @@ in SQLAlchemy core, including execution and connection pool events. For ORM event documentation, see :ref:`interfaces_orm_toplevel`. -A new version of this API with a significantly more flexible and consistent -interface will be available in version 0.7. +.. versionadded:: 0.7 + A new version of this API with a significantly more flexible and consistent + interface will be available in version 0.7. Execution, Connection and Cursor Events --------------------------------------- diff --git a/doc/build/intro.rst b/doc/build/intro.rst index 13ce8bff7d..4a5bcb35fc 100644 --- a/doc/build/intro.rst +++ b/doc/build/intro.rst @@ -102,8 +102,11 @@ Installing the C Extensions ---------------------------------- SQLAlchemy includes C extensions which provide an extra speed boost for -dealing with result sets. In version 0.6, these extensions must be explicitly -enabled (in 0.7 they will build by default). +dealing with result sets. + +.. versionchanged:: 0.7 + In version 0.6, these extensions must be explicitly + enabled (in 0.7 they will build by default). To install including building the C extensions, use the ``--with-cextensions`` flag. This flag must be on the command line before the actual install or build command:: diff --git a/doc/build/orm/interfaces.rst b/doc/build/orm/interfaces.rst index 8850a41eac..8b671325a4 100644 --- a/doc/build/orm/interfaces.rst +++ b/doc/build/orm/interfaces.rst @@ -11,8 +11,9 @@ within the SQLAlchemy ORM. For non-ORM event documentation, see :ref:`interfaces_core_toplevel`. -A new version of this API with a significantly more flexible and consistent -interface will be available in version 0.7. +.. versionadded:: 0.7 + A new version of this API with a significantly more flexible and consistent + interface will be available in version 0.7. Mapper Events ----------------- diff --git a/doc/build/orm/mapper_config.rst b/doc/build/orm/mapper_config.rst index 486c3f8cbe..6560d32f50 100644 --- a/doc/build/orm/mapper_config.rst +++ b/doc/build/orm/mapper_config.rst @@ -73,13 +73,17 @@ In some cases, multiple columns may have the same name, such as when mapping to a join of two or more tables that share some column name. To exclude or include individual columns, :class:`.Column` objects may also be placed within the "include_properties" and "exclude_properties" -collections (new feature as of 0.6.4):: +collections:: mapper(UserAddress, users_table.join(addresses_table), exclude_properties=[addresses_table.c.id], primary_key=[users_table.c.id] ) +.. versionadded:: 0.6.4 + :class:`.Column` objects may also be placed within + the "include_properties" and "exclude_properties" collections. + It should be noted that insert and update defaults configured on individal :class:`.Column` objects, such as those configured by the "default", "on_update", "server_default" and "server_onupdate" arguments, will continue diff --git a/doc/build/orm/session.rst b/doc/build/orm/session.rst index 11d0bd95c0..a92d808246 100644 --- a/doc/build/orm/session.rst +++ b/doc/build/orm/session.rst @@ -519,9 +519,10 @@ is extremely convenient. The solution here would usually be to not assign ``a1.user`` to an object already persistent in the target session. -Note that a new :func:`.relationship` option introduced in 0.6.5, -``cascade_backrefs=False``, will also prevent the ``Address`` from -being added to the session via the ``a1.user = u1`` assignment. +.. versionadded:: 0.6.5 + Note that new :func:`.relationship` option, + ``cascade_backrefs=False``, will also prevent the ``Address`` from + being added to the session via the ``a1.user = u1`` assignment. Further detail on cascade operation is at :ref:`unitofwork_cascades`. @@ -930,7 +931,11 @@ is already present in a session will also be added to that same session. relationship()-based attribute, meaning that objects which were removed from a scalar or collection attribute whose changes have not yet been flushed are also placed into the new session - this so that foreign key clear operations -and deletions will take place (new in 0.6). +and deletions will take place. + +.. versionadded:: 0.6 + ``save-update`` cascading the pending history of + a relationship()-based attribute. Note that the ``delete-orphan`` cascade only functions for relationships where the target object can have a single parent at a time, meaning it is only @@ -969,13 +974,16 @@ place:: >>> i1 in session True -This behavior can be disabled as of 0.6.5 using the ``cascade_backrefs`` flag:: +This behavior can be disabled using the ``cascade_backrefs`` flag:: mapper(Order, order_table, properties={ 'items' : relationship(Item, backref='order', cascade_backrefs=False) }) +.. versionadded:: 0.6.5 + Disabling the ``save-update`` cascade by the ``cascade_backrefs`` flag. + So above, the assignment of ``i1.order = o1`` will append ``i1`` to the ``items`` collection of ``o1``, but will not add ``i1`` to the session. You can, of course, :func:`~.Session.add` ``i1`` to the session at a later point. This option @@ -983,7 +991,6 @@ may be helpful for situations where an object needs to be kept out of a session until it's construction is completed, but still needs to be given associations to objects which are already persistent in the target session. - .. _unitofwork_transaction: Managing Transactions diff --git a/doc/build/orm/tutorial.rst b/doc/build/orm/tutorial.rst index cf904078e2..4b8e535948 100644 --- a/doc/build/orm/tutorial.rst +++ b/doc/build/orm/tutorial.rst @@ -890,8 +890,7 @@ from ``Address`` to ``User`` it is **many to one**, and from ``User`` to ``Address`` it is **one to many**. SQLAlchemy is automatically aware of many-to-one/one-to-many based on foreign keys. -.. note:: - +.. versionchanged:: 0.6beta2 The :func:`~sqlalchemy.orm.relationship()` function has historically been known as :func:`~sqlalchemy.orm.relation()`, which is the name that's available in all versions of SQLAlchemy prior to 0.6beta2, including the 0.5