fixes

2 files changed, 14 insertions, 11 deletions

diff --git a/doc/build/orm/collections.rst b/doc/build/orm/collections.rst
index a9a160d9d..73ba1277b 100644
--- a/doc/build/orm/collections.rst
+++ b/doc/build/orm/collections.rst
@@ -51,17 +51,20 @@ applied as well as limits and offsets, either explicitly or via array slices:
     posts = jack.posts[5:20]
 
 The dynamic relationship supports limited write operations, via the
-``append()`` and ``remove()`` methods. Since the read side of the dynamic
-relationship always queries the database, changes to the underlying collection
-will not be visible until the data has been flushed:
-
-.. sourcecode:: python+sql
+``append()`` and ``remove()`` methods::
 
     oldpost = jack.posts.filter(Post.headline=='old post').one()
     jack.posts.remove(oldpost)
 
     jack.posts.append(Post('new post'))
 
+Since the read side of the dynamic relationship always queries the 
+database, changes to the underlying collection will not be visible 
+until the data has been flushed.  However, as long as "autoflush" is 
+enabled on the :class:`.Session` in use, this will occur 
+automatically each time the collection is about to emit a 
+query.
+
 To place a dynamic relationship on a backref, use ``lazy='dynamic'``:
 
 .. sourcecode:: python+sql
@@ -135,7 +138,7 @@ values accessible through an attribute on the parent instance. By default,
 this collection is a ``list``::
 
     mapper(Parent, properties={
-        children = relationship(Child)
+        'children' : relationship(Child)
     })
 
     parent = Parent()
@@ -151,7 +154,7 @@ default list, by specifying the ``collection_class`` option on
 
     # use a set
     mapper(Parent, properties={
-        children = relationship(Child, collection_class=set)
+        'children' : relationship(Child, collection_class=set)
     })
 
     parent = Parent()
diff --git a/doc/build/orm/inheritance.rst b/doc/build/orm/inheritance.rst
index 71b3fb820..65bcd06f9 100644
--- a/doc/build/orm/inheritance.rst
+++ b/doc/build/orm/inheritance.rst
@@ -237,7 +237,7 @@ Using :func:`~sqlalchemy.orm.query.Query.with_polymorphic` with
 ``with_polymorphic`` setting.
 
 Advanced Control of Which Tables are Queried
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
++++++++++++++++++++++++++++++++++++++++++++++
 
 The :meth:`.Query.with_polymorphic` method and configuration works fine for
 simplistic scenarios. However, it currently does not work with any
@@ -249,8 +249,8 @@ use the :class:`.Table` objects directly and construct joins manually.  For exam
 query the name of employees with particular criterion::
 
     session.query(Employee.name).\
-        outerjoin((engineer, engineer.c.employee_id==Employee.c.employee_id)).\
-        outerjoin((manager, manager.c.employee_id==Employee.c.employee_id)).\
+        outerjoin((engineer, engineer.c.employee_id==Employee.employee_id)).\
+        outerjoin((manager, manager.c.employee_id==Employee.employee_id)).\
         filter(or_(Engineer.engineer_info=='w', Manager.manager_data=='q'))
 
 The base table, in this case the "employees" table, isn't always necessary. A
@@ -265,7 +265,7 @@ what's specified in the :meth:`.Session.query`, :meth:`.Query.filter`, or
     session.query(engineer.c.id).filter(engineer.c.engineer_info==manager.c.manager_data)
 
 Creating Joins to Specific Subtypes
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
++++++++++++++++++++++++++++++++++++
 
 The :func:`~sqlalchemy.orm.interfaces.PropComparator.of_type` method is a
 helper which allows the construction of joins along