4 files changed, 9 insertions, 9 deletions
diff --git a/doc/build/orm/events.rst b/doc/build/orm/events.rst
index 2be74bf57..6f2e0cb29 100644
--- a/doc/build/orm/events.rst
+++ b/doc/build/orm/events.rst
@@ -6,7 +6,7 @@ ORM Events
 The ORM includes a wide variety of hooks available for subscription.
 
 .. versionadded:: 0.7
-    The event supercedes the previous system of "extension" classes.
+    The event supersedes the previous system of "extension" classes.
 
 For an introduction to the event API, see :ref:`event_toplevel`.  Non-ORM events
 such as those regarding connections and low-level statement execution are described in 
diff --git a/doc/build/orm/loading.rst b/doc/build/orm/loading.rst
index 816052340..6c2fac004 100644
--- a/doc/build/orm/loading.rst
+++ b/doc/build/orm/loading.rst
@@ -168,7 +168,7 @@ the string ``'*'`` as the argument to any of these options::
 
     session.query(MyClass).options(lazyload('*'))
 
-Above, the ``lazyload('*')`` option will supercede the ``lazy`` setting
+Above, the ``lazyload('*')`` option will supersede the ``lazy`` setting
 of all :func:`.relationship` constructs in use for that query,
 except for those which use the ``'dynamic'`` style of loading.
 If some relationships specify
@@ -177,7 +177,7 @@ using ``lazyload('*')`` will unilaterally
 cause all those relationships to use ``'select'`` loading, e.g. emit a
 SELECT statement when each attribute is accessed.
 
-The option does not supercede loader options stated in the
+The option does not supersede loader options stated in the
 query, such as :func:`.eagerload`,
 :func:`.subqueryload`, etc.  The query below will still use joined loading
 for the ``widget`` relationship::
diff --git a/doc/build/orm/mapper_config.rst b/doc/build/orm/mapper_config.rst
index 2cf61d06c..9139b53f0 100644
--- a/doc/build/orm/mapper_config.rst
+++ b/doc/build/orm/mapper_config.rst
@@ -942,7 +942,7 @@ using the :func:`.synonym_for` decorator::
 While the :func:`.synonym` is useful for simple mirroring, the use case
 of augmenting attribute behavior with descriptors is better handled in modern
 usage using the :ref:`hybrid attribute <mapper_hybrids>` feature, which
-is more oriented towards Python descriptors.   Techically, a :func:`.synonym`
+is more oriented towards Python descriptors.   Technically, a :func:`.synonym`
 can do everything that a :class:`.hybrid_property` can do, as it also supports
 injection of custom SQL capabilities, but the hybrid is more straightforward
 to use in more complex situations.
@@ -1464,7 +1464,7 @@ following::
 The above UPDATE statement is updating the row that not only matches
 ``user.id = 1``, it also is requiring that ``user.version_id = 1``, where "1"
 is the last version identifier we've been known to use on this object.
-If a transaction elsewhere has modifed the row independently, this version id
+If a transaction elsewhere has modified the row independently, this version id
 will no longer match, and the UPDATE statement will report that no rows matched;
 this is the condition that SQLAlchemy tests, that exactly one row matched our
 UPDATE (or DELETE) statement.  If zero rows match, that indicates our version
diff --git a/doc/build/orm/session.rst b/doc/build/orm/session.rst
index ec96324d5..657d8e4b5 100644
--- a/doc/build/orm/session.rst
+++ b/doc/build/orm/session.rst
@@ -634,7 +634,7 @@ When given an instance, it follows these steps:
 * The new instance is returned.
 
 With :meth:`~.Session.merge`, the given "source"
-instance is not modifed nor is it associated with the target :class:`.Session`,
+instance is not modified nor is it associated with the target :class:`.Session`,
 and remains available to be merged with any number of other :class:`.Session`
 objects.  :meth:`~.Session.merge` is useful for
 taking the state of any kind of object structure without regard for its
@@ -686,7 +686,7 @@ Merge Tips
 
 :meth:`~.Session.merge` is an extremely useful method for many purposes.  However,
 it deals with the intricate border between objects that are transient/detached and
-those that are persistent, as well as the automated transferrence of state.
+those that are persistent, as well as the automated transference of state.
 The wide variety of scenarios that can present themselves here often require a
 more careful approach to the state of objects.   Common problems with merge usually involve
 some unexpected state regarding the object being passed to :meth:`~.Session.merge`.
@@ -1523,7 +1523,7 @@ deleting the row entirely.
       relationship, SQLAlchemy's default behavior of setting a foreign key
       to ``NULL`` can be caught in one of two ways:
 
-        * The easiest and most common is just to to set the
+        * The easiest and most common is just to set the
           foreign-key-holding column to ``NOT NULL`` at the database schema
           level.  An attempt by SQLAlchemy to set the column to NULL will
           fail with a simple NOT NULL constraint exception.
@@ -1823,7 +1823,7 @@ is closed out after the :meth:`.Session.flush` operation completes.
     of usage, and can in some cases lead to concurrent connection
     checkouts.
 
-    In the absense of a demarcated transaction, the :class:`.Session`
+    In the absence of a demarcated transaction, the :class:`.Session`
     cannot make appropriate decisions as to when autoflush should
     occur nor when auto-expiration should occur, so these features
     should be disabled with ``autoflush=False, expire_on_commit=False``.