it were only against a table that's now being replaced. It also allows for
correct behavior when constructing a :func:`_orm.aliased` without a
selectable argument against a :func:`_orm.aliased` that's against a
- subuquery, to create an alias of that subquery (i.e. to change its name).
+ subquery, to create an alias of that subquery (i.e. to change its name).
The nesting behavior of :func:`_orm.aliased` remains in place for the case
where the outer :func:`_orm.aliased` object is against a subquery which in
columns clause of a :class:`_sql.Select` construct, which is better handled
by using a :func:`_sql.literal_column` construct, would nonetheless prevent
constructs like :func:`_sql.union` from working correctly. Other use cases,
- such as constructing subuqeries, continue to work the same as in prior
+ such as constructing subqueries, continue to work the same as in prior
versions where the :func:`_sql.text` construct is silently omitted from the
collection of exported columns. Also repairs similar use within the
ORM.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The :func:`_orm.aliased` construct discussed in the previous section
-can be used with any :class:`_sql.Subuqery` construct that comes from a
+can be used with any :class:`_sql.Subquery` construct that comes from a
method such as :meth:`_sql.Select.subquery` to link ORM entities to the
columns returned by that subquery; there must be a **column correspondence**
relationship between the columns delivered by the subquery and the columns
^^^^^^^^^^^^^^^^^^^^^
The target of a join may be any "selectable" entity which includes
-subuqeries. When using the ORM, it is typical
+subqueries. When using the ORM, it is typical
that these targets are stated in terms of an
:func:`_orm.aliased` construct, but this is not strictly required, particularly
if the joined entity is not being returned in the results. For example, to join from the
projects / thirdparty / sqlalchemy / sqlalchemy.git / commitdiff
