Spelling fixespr/266

9 files changed, 19 insertions, 19 deletions

diff --git a/doc/build/orm/extensions/baked.rst b/doc/build/orm/extensions/baked.rst
index 83cee51da..4515067c8 100644
--- a/doc/build/orm/extensions/baked.rst
+++ b/doc/build/orm/extensions/baked.rst
@@ -10,7 +10,7 @@ Baked Queries
 construction and string-compilation steps.  This means that for a
 particular :class:`~.query.Query` building scenario that is used more than
 once, all of the Python function invocation involved in building the query
-from its initial construction up through generating a SQL string will only
+from its initial construction up through generating an SQL string will only
 occur **once**, rather than for each time that query is built up and executed.
 
 The rationale for this system is to greatly reduce Python interpreter
@@ -155,7 +155,7 @@ as being impacted by this particular form of overhead.
 
 .. topic:: Measure twice, cut once
 
-    For background on how to profile a SQLAlchemy application, please see
+    For background on how to profile an SQLAlchemy application, please see
     the section :ref:`faq_performance`.  It is essential that performance
     measurement techniques are used when attempting to improve the performance
     of an application.
diff --git a/doc/build/orm/extensions/declarative/relationships.rst b/doc/build/orm/extensions/declarative/relationships.rst
index fb53c28bb..fc9dc114f 100644
--- a/doc/build/orm/extensions/declarative/relationships.rst
+++ b/doc/build/orm/extensions/declarative/relationships.rst
@@ -130,7 +130,7 @@ as well, passing the string name of the table as defined in the
         id = Column(Integer, primary_key=True)
         keywords = relationship("Keyword", secondary="keywords")
 
-As with traditional mapping, its generally not a good idea to use
+As with traditional mapping, it's generally not a good idea to use
 a :class:`.Table` as the "secondary" argument which is also mapped to
 a class, unless the :func:`.relationship` is declared with ``viewonly=True``.
 Otherwise, the unit-of-work system may attempt duplicate INSERT and
diff --git a/doc/build/orm/loading_relationships.rst b/doc/build/orm/loading_relationships.rst
index 3a0026bbe..aa993c359 100644
--- a/doc/build/orm/loading_relationships.rst
+++ b/doc/build/orm/loading_relationships.rst
@@ -15,7 +15,7 @@ Using Loader Strategies: Lazy Loading, Eager Loading
 By default, all inter-object relationships are **lazy loading**. The scalar or
 collection attribute associated with a :func:`~sqlalchemy.orm.relationship`
 contains a trigger which fires the first time the attribute is accessed.  This
-trigger, in all but one case, issues a SQL call at the point of access
+trigger, in all but one case, issues an SQL call at the point of access
 in order to load the related object or objects:
 
 .. sourcecode:: python+sql
diff --git a/doc/build/orm/mapped_attributes.rst b/doc/build/orm/mapped_attributes.rst
index 2e7e9b3eb..260041ebc 100644
--- a/doc/build/orm/mapped_attributes.rst
+++ b/doc/build/orm/mapped_attributes.rst
@@ -156,7 +156,7 @@ usable with :class:`.Query`. To provide these, we instead use the
             self._email = email
 
 The ``.email`` attribute, in addition to providing getter/setter behavior when we have an
-instance of ``EmailAddress``, also provides a SQL expression when used at the class level,
+instance of ``EmailAddress``, also provides an SQL expression when used at the class level,
 that is, from the ``EmailAddress`` class directly:
 
 .. sourcecode:: python+sql
@@ -210,7 +210,7 @@ logic::
 
         @email.expression
         def email(cls):
-            """Produce a SQL expression that represents the value
+            """Produce an SQL expression that represents the value
             of the _email column, minus the last twelve characters."""
 
             return func.substr(cls._email, 0, func.length(cls._email) - 12)
@@ -218,7 +218,7 @@ logic::
 Above, accessing the ``email`` property of an instance of ``EmailAddress``
 will return the value of the ``_email`` attribute, removing or adding the
 hostname ``@example.com`` from the value. When we query against the ``email``
-attribute, a SQL function is rendered which produces the same effect:
+attribute, an SQL function is rendered which produces the same effect:
 
 .. sourcecode:: python+sql
 
diff --git a/doc/build/orm/mapped_sql_expr.rst b/doc/build/orm/mapped_sql_expr.rst
index e091e33a6..63595440b 100644
--- a/doc/build/orm/mapped_sql_expr.rst
+++ b/doc/build/orm/mapped_sql_expr.rst
@@ -75,7 +75,7 @@ needs to be present inside the hybrid, using the ``if`` statement in Python and
 Using column_property
 ---------------------
 
-The :func:`.orm.column_property` function can be used to map a SQL
+The :func:`.orm.column_property` function can be used to map an SQL
 expression in a manner similar to a regularly mapped :class:`.Column`.
 With this technique, the attribute is loaded
 along with all other column-mapped attributes at load time.  This is in some
@@ -176,7 +176,7 @@ here with a classical mapping::
 Using a plain descriptor
 -------------------------
 
-In cases where a SQL query more elaborate than what :func:`.orm.column_property`
+In cases where an SQL query more elaborate than what :func:`.orm.column_property`
 or :class:`.hybrid_property` can provide must be emitted, a regular Python
 function accessed as an attribute can be used, assuming the expression
 only needs to be available on an already-loaded instance.   The function
@@ -204,5 +204,5 @@ which is then used to emit a query::
 
 The plain descriptor approach is useful as a last resort, but is less performant
 in the usual case than both the hybrid and column property approaches, in that
-it needs to emit a SQL query upon each access.
+it needs to emit an SQL query upon each access.
 
diff --git a/doc/build/orm/persistence_techniques.rst b/doc/build/orm/persistence_techniques.rst
index a30d486b5..f679c5c15 100644
--- a/doc/build/orm/persistence_techniques.rst
+++ b/doc/build/orm/persistence_techniques.rst
@@ -7,7 +7,7 @@ Additional Persistence Techniques
 Embedding SQL Insert/Update Expressions into a Flush
 =====================================================
 
-This feature allows the value of a database column to be set to a SQL
+This feature allows the value of a database column to be set to an SQL
 expression instead of a literal value. It's especially useful for atomic
 updates, calling stored procedures, etc. All you do is assign an expression to
 an attribute::
@@ -18,7 +18,7 @@ an attribute::
 
     someobject = session.query(SomeClass).get(5)
 
-    # set 'value' attribute to a SQL expression adding one
+    # set 'value' attribute to an SQL expression adding one
     someobject.value = some_table.c.value + 1
 
     # issues "UPDATE some_table SET value=value+1"
@@ -48,7 +48,7 @@ This is most easily accomplished using the
     # execute a string statement
     result = session.execute("select * from table where id=:id", {'id':7})
 
-    # execute a SQL expression construct
+    # execute an SQL expression construct
     result = session.execute(select([mytable]).where(mytable.c.id==7))
 
 The current :class:`~sqlalchemy.engine.Connection` held by the
diff --git a/doc/build/orm/session_basics.rst b/doc/build/orm/session_basics.rst
index 0f96ba50a..2fbb5082f 100644
--- a/doc/build/orm/session_basics.rst
+++ b/doc/build/orm/session_basics.rst
@@ -681,7 +681,7 @@ initiated by calling the :meth:`~.Session.begin` method.
    construct within the :class:`.Session` itself which may be
    maintaining zero or more actual database (DBAPI) transactions.  An individual
    DBAPI connection begins participation in the "transaction" as it is first
-   used to execute a SQL statement, then remains present until the session-level
+   used to execute an SQL statement, then remains present until the session-level
    "transaction" is completed.  See :ref:`unitofwork_transaction` for
    further detail.
 
diff --git a/doc/build/orm/session_state_management.rst b/doc/build/orm/session_state_management.rst
index 090bf7674..1a4a879c9 100644
--- a/doc/build/orm/session_state_management.rst
+++ b/doc/build/orm/session_state_management.rst
@@ -416,7 +416,7 @@ Refreshing / Expiring
 
 :term:`Expiring` means that the database-persisted data held inside a series
 of object attributes is erased, in such a way that when those attributes
-are next accessed, a SQL query is emitted which will refresh that data from
+are next accessed, an SQL query is emitted which will refresh that data from
 the database.
 
 When we talk about expiration of data we are usually talking about an object
@@ -599,7 +599,7 @@ may have occurred.
     can't fully predict when the same SELECT statement, emitted a second time,
     will definitely return the data we already have, or will return new data.
     So as a best guess, it assumes that within the scope of a transaction, unless
-    it is known that a SQL expression has been emitted to modify a particular row,
+    it is known that an SQL expression has been emitted to modify a particular row,
     there's no need to refresh a row unless explicitly told to do so.
 
 The :meth:`.Session.expire` and :meth:`.Session.refresh` methods are used in
diff --git a/doc/build/orm/tutorial.rst b/doc/build/orm/tutorial.rst
index 0a9fc7430..cd5536b7a 100644
--- a/doc/build/orm/tutorial.rst
+++ b/doc/build/orm/tutorial.rst
@@ -148,7 +148,7 @@ is described in detail at :ref:`declarative_mixins`.
 When our class is constructed, Declarative replaces all the :class:`.Column`
 objects with special Python accessors known as :term:`descriptors`; this is a
 process known as :term:`instrumentation`.   The "instrumented" mapped class
-will provide us with the means to refer to our table in a SQL context as well
+will provide us with the means to refer to our table in an SQL context as well
 as to persist and load the values of columns from the database.
 
 Outside of what the mapping process does to our class, the class remains
@@ -1429,7 +1429,7 @@ get rows back for those users who don't have any addresses, e.g.::
         ON users.id=adr_count.user_id
 
 Using the :class:`~sqlalchemy.orm.query.Query`, we build a statement like this
-from the inside out. The ``statement`` accessor returns a SQL expression
+from the inside out. The ``statement`` accessor returns an SQL expression
 representing the statement generated by a particular
 :class:`~sqlalchemy.orm.query.Query` - this is an instance of a :func:`~.expression.select`
 construct, which are described in :ref:`sqlexpression_toplevel`::
@@ -1440,7 +1440,7 @@ construct, which are described in :ref:`sqlexpression_toplevel`::
     ...         group_by(Address.user_id).subquery()
 
 The ``func`` keyword generates SQL functions, and the ``subquery()`` method on
-:class:`~sqlalchemy.orm.query.Query` produces a SQL expression construct
+:class:`~sqlalchemy.orm.query.Query` produces an SQL expression construct
 representing a SELECT statement embedded within an alias (it's actually
 shorthand for ``query.statement.alias()``).