summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorMike Bayer <mike_mp@zzzcomputing.com>2009-01-07 01:13:29 +0000
committerMike Bayer <mike_mp@zzzcomputing.com>2009-01-07 01:13:29 +0000
commitcacc64d809d88e558b8db9a026e2dc9301918e5e (patch)
tree5c282bf9b6ea1809c40e35e91af9828fb94d89b3
parent4220fc094356d713156f6aaa17dba785a7e9763b (diff)
downloadsqlalchemy-cacc64d809d88e558b8db9a026e2dc9301918e5e.tar.gz
typo
-rw-r--r--doc/build/mappers.rst4
1 files changed, 2 insertions, 2 deletions
diff --git a/doc/build/mappers.rst b/doc/build/mappers.rst
index bc0d59e31..138c530d4 100644
--- a/doc/build/mappers.rst
+++ b/doc/build/mappers.rst
@@ -658,7 +658,7 @@ Upon select, the polymorphic union produces a query like this:
Using Relations with Inheritance
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Both joined-table and single table inheritance scenarios produce mappings which are usable in relation() functions; that is, it's possible to map a parent object to a child object which is polymorphic. Similarly, inheriting mappers can have ``relation()``s of their own at any level, which are inherited to each child class. The only requirement for relations is that there is a table relationship between parent and child. An example is the following modification to the joined table inheritance example, which sets a bi-directional relationship between ``Employee`` and ``Company``:
+Both joined-table and single table inheritance scenarios produce mappings which are usable in relation() functions; that is, it's possible to map a parent object to a child object which is polymorphic. Similarly, inheriting mappers can have ``relation()`` objects of their own at any level, which are inherited to each child class. The only requirement for relations is that there is a table relationship between parent and child. An example is the following modification to the joined table inheritance example, which sets a bi-directional relationship between ``Employee`` and ``Company``:
.. sourcecode:: python+sql
@@ -804,7 +804,7 @@ Multiple Mappers for One Class
-------------------------------
-The first mapper created for a certain class is known as that class's "primary mapper." Other mappers can be created as well on the "load side" - these are called **secondary mappers**. This is a mapper that must be constructed with the keyword argument ``non_primary=True``, and represents a load-only mapper. Objects that are loaded with a secondary mapper will have their save operation processed by the primary mapper. It is also invalid to add new ``relation()``s to a non-primary mapper. To use this mapper with the Session, specify it to the ``query`` method:
+The first mapper created for a certain class is known as that class's "primary mapper." Other mappers can be created as well on the "load side" - these are called **secondary mappers**. This is a mapper that must be constructed with the keyword argument ``non_primary=True``, and represents a load-only mapper. Objects that are loaded with a secondary mapper will have their save operation processed by the primary mapper. It is also invalid to add new ``relation()`` objects to a non-primary mapper. To use this mapper with the Session, specify it to the ``query`` method:
example: