From: Kevin Kirsche Date: Wed, 8 Sep 2021 19:14:56 +0000 (-0400) Subject: fix: typos in doc/build/tutorial (#7005) X-Git-Tag: rel_1_4_24~37 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=a4abb4e396e3d3463629edca360b815c6d0428f7;p=thirdparty%2Fsqlalchemy%2Fsqlalchemy.git fix: typos in doc/build/tutorial (#7005) --- diff --git a/doc/build/tutorial/data_insert.rst b/doc/build/tutorial/data_insert.rst index 14d7237fb6..90180154b7 100644 --- 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 6ff47087c1..0275319ee1 100644 --- 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 ea9b091f32..1aa20d1721 100644 --- 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 d92331def0..59691cf818 100644 --- 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 `, 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