backends; each is described as its own package in the :ref:`sqlalchemy.dialects_toplevel` package. A
SQLAlchemy dialect always requires that an appropriate DBAPI driver is installed.
-The table below summarizes the state of DBAPI support in SQLAlchemy 0.6. The values
+The table below summarizes the state of DBAPI support in SQLAlchemy 0.7. The values
translate as:
* yes / Python platform - The SQLAlchemy dialect is mostly or fully operational on the target platform.
=============
-A quick check to verify that we are on at least **version 0.6** of SQLAlchemy:
+A quick check to verify that we are on at least **version 0.7** of SQLAlchemy:
.. sourcecode:: pycon+sql
>>> import sqlalchemy
>>> sqlalchemy.__version__ # doctest:+SKIP
- 0.6.0
+ 0.7.0
Connecting
==========
Checking the Installed SQLAlchemy Version
=========================================
-This documentation covers SQLAlchemy version 0.6. If you're working on a system that already has SQLAlchemy installed, check the version from your Python prompt like this:
+This documentation covers SQLAlchemy version 0.7. If you're working on a system that already has SQLAlchemy installed, check the version from your Python prompt like this:
.. sourcecode:: python+sql
>>> import sqlalchemy
>>> sqlalchemy.__version__ # doctest: +SKIP
- 0.6.0
+ 0.7.0
-0.5 to 0.6 Migration
+0.6 to 0.7 Migration
=====================
-Notes on what's changed from 0.5 to 0.6 is available on the SQLAlchemy wiki at `06Migration <http://www.sqlalchemy.org/trac/wiki/06Migration>`_.
+Notes on what's changed from 0.6 to 0.7 is available on the SQLAlchemy wiki at `07Migration <http://www.sqlalchemy.org/trac/wiki/07Migration>`_.
Version Check
=============
-A quick check to verify that we are on at least **version 0.6** of SQLAlchemy::
+A quick check to verify that we are on at least **version 0.7** of SQLAlchemy::
>>> import sqlalchemy
>>> sqlalchemy.__version__ # doctest:+SKIP
- 0.6.0
+ 0.7.0
Connecting
==========
The above class introduces a **foreign key** constraint which references the ``users`` table. This defines for SQLAlchemy the relationship between the two tables at the database level. The relationship between the ``User`` and ``Address`` classes is defined separately using the :func:`~sqlalchemy.orm.relationship()` function, which defines an attribute ``user`` to be placed on the ``Address`` class, as well as an ``addresses`` collection to be placed on the ``User`` class. Such a relationship is known as a **bidirectional** relationship. Because of the placement of the foreign key, 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:: 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 and 0.4 series. :func:`~sqlalchemy.orm.relationship()` is only available starting with SQLAlchemy 0.6beta2. :func:`~sqlalchemy.orm.relation()` will remain available in SQLAlchemy for the foreseeable future to enable cross-compatibility.
+.. note:: The :func:`~sqlalchemy.orm.relationship()` function has historically been known as :func:`~sqlalchemy.orm.relation()` in the 0.5 series of SQLAlchemy and earlier.
The :func:`~sqlalchemy.orm.relationship()` function is extremely flexible, and could just have easily been defined on the ``User`` class:
projects / thirdparty / sqlalchemy / sqlalchemy.git / commitdiff
