fix: typos in doc/build/tutorial (#7005)

diff --git a/doc/build/tutorial/data_insert.rst b/doc/build/tutorial/data_insert.rst
index 14d7237fb635fdabd962973a2a186d34b2c96800..90180154b7d7a6a8e6a6425d3f91394c69b58feb 100644 (file)
--- a/doc/build/tutorial/data_insert.rst
+++ b/doc/build/tutorial/data_insert.rst
@@ -98,7 +98,7 @@ first integer primary key value, which we can acquire using the
 
 .. versionchanged:: 1.4.8 the tuple returned by
    :attr:`_engine.CursorResult.inserted_primary_key` is now a named tuple
-   fullfilled by returning it as a :class:`_result.Row` object.
+   fulfilled by returning it as a :class:`_result.Row` object.
 
 .. _tutorial_core_insert_values_clause:
 

diff --git a/doc/build/tutorial/data_select.rst b/doc/build/tutorial/data_select.rst
index 6ff47087c14f82d683957ef37a7e7415af829f31..0275319ee1c37e22df23da482c4c265070ea0c13 100644 (file)
--- a/doc/build/tutorial/data_select.rst
+++ b/doc/build/tutorial/data_select.rst
@@ -677,7 +677,7 @@ Using Aliases
 ^^^^^^^^^^^^^
 
 Now that we are selecting from multiple tables and using joins, we quickly
-run into the case where we need to refer to the same table mutiple times
+run into the case where we need to refer to the same table multiple times
 in the FROM clause of a statement.  We accomplish this using SQL **aliases**,
 which are a syntax that supplies an alternative name to a table or subquery
 from which it can be referred towards in the statement.

diff --git a/doc/build/tutorial/index.rst b/doc/build/tutorial/index.rst
index ea9b091f323135dc84b6cf769d61bf0472978b34..1aa20d1721b329aa9ad5b4d44cdb86a80dd8a31a 100644 (file)
--- a/doc/build/tutorial/index.rst
+++ b/doc/build/tutorial/index.rst
@@ -155,7 +155,7 @@ used, which will be seen as the tutorial describes the :class:`_engine.Engine`
 and :class:`_orm.Session` objects.   These flags fully enable 2.0-compatibility
 mode and allow the code in the tutorial to proceed fully.  When using the
 ``future`` flag with the :func:`_sa.create_engine` function, the object
-returned is a sublass of :class:`sqlalchemy.engine.Engine` described as
+returned is a subclass of :class:`sqlalchemy.engine.Engine` described as
 :class:`sqlalchemy.future.Engine`. This tutorial will be referring to
 :class:`sqlalchemy.future.Engine`.
 

diff --git a/doc/build/tutorial/orm_related_objects.rst b/doc/build/tutorial/orm_related_objects.rst
index d92331def0bd182f5ff197aade7ea54ab7b1b8a5..59691cf818da57f352ca0653a68c5c3c4b5493e4 100644 (file)
--- a/doc/build/tutorial/orm_related_objects.rst
+++ b/doc/build/tutorial/orm_related_objects.rst
@@ -531,7 +531,7 @@ a handful of unloaded attributes, routine manipulation of these objects can
 spin off many additional queries that can add up (otherwise known as the
 :term:`N plus one problem`), and to make matters worse they are emitted
 implicitly.    These implicit queries may not be noticed, may cause errors
-when they are attempted after there's no longer a database tranasction
+when they are attempted after there's no longer a database transaction
 available, or when using alternative concurrency patterns such as :ref:`asyncio
 <asyncio_toplevel>`, they actually won't work at all.
 
@@ -642,7 +642,7 @@ which can then load in related objects.
 The :func:`_orm.joinedload` strategy is best suited towards loading
 related many-to-one objects, as this only requires that additional columns
 are added to a primary entity row that would be fetched in any case.
-For greater effiency, it also accepts an option :paramref:`_orm.joinedload.innerjoin`
+For greater efficiency, it also accepts an option :paramref:`_orm.joinedload.innerjoin`
 so that an inner join instead of an outer join may be used for a case such
 as below where we know that all ``Address`` objects have an associated
 ``User``:
@@ -716,7 +716,7 @@ using a method such as :meth:`_sql.Select.join` to render the JOIN, we could
 also leverage that JOIN in order to eagerly load the contents of the
 ``Address.user`` attribute on each ``Address`` object returned.  This is
 essentially that we are using "joined eager loading" but rendering the JOIN
-ourselves.   This common use case is acheived by using the
+ourselves.   This common use case is achieved by using the
 :func:`_orm.contains_eager` option. This option is very similar to
 :func:`_orm.joinedload`, except that it assumes we have set up the JOIN
 ourselves, and it instead only indicates that additional columns in the COLUMNS