value the DBAPI offers for any kind of statement will be available using
the :attr:`_engine.CursorResult.rowcount` attribute from the
:class:`_engine.CursorResult`. This allows the rowcount to be accessed for
- statments such as INSERT and SELECT, to the degree supported by the DBAPI
+ statements such as INSERT and SELECT, to the degree supported by the DBAPI
in use. The :ref:`engine_insertmanyvalues` also supports this option and
will ensure :attr:`_engine.CursorResult.rowcount` is correctly set for a
bulk INSERT of rows when set.
:meth:`_orm.Session.bulk_insert_mappings`, with additional enhancements. This will optimize the
batching of rows making use of the new :ref:`fast insertmany <change_6047>`
feature, while also adding support for
-heterogenous parameter sets and multiple-table mappings like joined table
+heterogeneous parameter sets and multiple-table mappings like joined table
inheritance::
>>> users = session.scalars(
.. note:: Since version 2.0 the built-in :class:`_types.Uuid` type that
behaves similarly should be preferred. This example is presented
- just as an example of a type decorator that recieves and returns
+ just as an example of a type decorator that receives and returns
python objects.
Receives and returns Python uuid() objects.
using the :meth:`_sql.ColumnOperators.__eq__` overloaded operator, i.e.
``==``, in conjunction with the ``None`` or :func:`_sql.null` value. In this
way, there's typically not a need to use :meth:`_sql.ColumnOperators.is_`
- explicitly, paricularly when used with a dynamic value::
+ explicitly, particularly when used with a dynamic value::
>>> a = None
>>> print(column("x") == a)
* :doc:`Frequently Asked Questions <faq/index>` - A collection of common problems and solutions
* :doc:`Glossary <glossary>` - Terms used in SQLAlchemy's documentation
- * :doc:`Error Message Guide <errors>` - Explainations of many SQLAlchemy Errors
+ * :doc:`Error Message Guide <errors>` - Explanations of many SQLAlchemy Errors
* :doc:`Complete table of of contents <contents>`
* :ref:`Index <genindex>`
In the absence of :paramref:`_orm.relationship.collection_class`
or :class:`_orm.Mapped`, the default collection type is ``list``.
-Beyond ``list`` and ``set`` builtins, there is also support for two varities of
+Beyond ``list`` and ``set`` builtins, there is also support for two varieties of
dictionary, described below at :ref:`orm_dictionary_collection`. There is also
support for any arbitrary mutable sequence type can be set up as the target
collection, with some additional configuration steps; this is described in the
The :func:`_orm.composite` construct may be passed the relevant columns
using a :func:`_orm.mapped_column` construct, a :class:`_schema.Column`,
or the string name of an existing mapped column. The following examples
-illustrate an equvalent mapping as that of the main section above.
+illustrate an equivalent mapping as that of the main section above.
* Map columns directly, then pass to composite
The above mapping will generate an empty list for ``Parent.children`` when a
new ``Parent()`` object is constructed without passing ``children``, and
similarly a ``None`` value for ``Child.parent`` when a new ``Child()`` object
-is constructed without passsing ``parent``.
+is constructed without passing ``parent``.
While the :paramref:`_orm.relationship.default_factory` can be automatically
derived from the given collection class of the :func:`_orm.relationship`
In the absence of **both** of these parameters, the presence of
``typing.Optional[]`` within the :class:`_orm.Mapped` type annotation will be
used to determine nullability, where ``typing.Optional[]`` means ``NULL``,
- and the absense of ``typing.Optional[]`` means ``NOT NULL``. If there is no
+ and the absence of ``typing.Optional[]`` means ``NOT NULL``. If there is no
``Mapped[]`` annotation present at all, and there is no
:paramref:`_orm.mapped_column.nullable` or
:paramref:`_orm.mapped_column.primary_key` parameter, then SQLAlchemy's usual
When using ``Annotated`` types in this way, the configuration of the type
may also be affected on a per-attribute basis. For the types in the above
-example that feature explcit use of :paramref:`_orm.mapped_column.nullable`,
+example that feature explicit use of :paramref:`_orm.mapped_column.nullable`,
we can apply the ``Optional[]`` generic modifier to any of our types so that
the field is optional or not at the Python level, which will be independent
of the ``NULL`` / ``NOT NULL`` setting that takes place in the database::
The ``"auto"`` setting of :paramref:`_orm.Mapper.eager_defaults` means that
a backend that supports RETURNING will usually make use of RETURNING with
-INSERT statements in order to retreive newly generated default values.
+INSERT statements in order to retrieve newly generated default values.
However there are limitations of server-generated values that are generated
using triggers, such that RETURNING can't be used:
On SQL Server with the pyodbc driver, an INSERT for the above table will
not use RETURNING and will use the SQL Server ``scope_identity()`` function
-to retreive the newly generated primary key value:
+to retrieve the newly generated primary key value:
.. sourcecode:: sql
...
sqlalchemy.exc.InvalidRequestError: 'Book.summary' is not available due to raiseload=True
-Only by overridding their behavior at query time, typically using
+Only by overriding their behavior at query time, typically using
:func:`_orm.undefer` or :func:`_orm.undefer_group`, or less commonly
:func:`_orm.defer`, may the attributes be loaded. The example below applies
``undefer('*')`` to undefer all attributes, also making use of
.. _orm_queryguide_insert_heterogeneous_params:
-Using Heterogenous Parameter Dictionaries
+Using Heterogeneous Parameter Dictionaries
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.. Setup code, not for display
BEGIN (implicit)...
The ORM bulk insert feature supports lists of parameter dictionaries that are
-"heterogenous", which basically means "individual dictionaries can have different
+"heterogeneous", which basically means "individual dictionaries can have different
keys". When this condition is detected,
the ORM will break up the parameter dictionaries into groups corresponding
to each set of keys and batch accordingly into separate INSERT statements::
or other multi-table mappings are not supported, since that would require multiple
INSERT statements.
-* :ref:`Heterogenous parameter sets <orm_queryguide_insert_heterogeneous_params>`
+* :ref:`Heterogeneous parameter sets <orm_queryguide_insert_heterogeneous_params>`
are not supported - each element in the VALUES set must have the same
columns.
* :attr:`_engine.CursorResult.rowcount` is not necessarily available for an UPDATE
or DELETE statement that uses RETURNING, or for one that uses an
- :ref:`executemany <tutorial_multiple_parameters>` execution. The availablility
+ :ref:`executemany <tutorial_multiple_parameters>` execution. The availability
depends on the DBAPI module in use.
* In any case where the DBAPI does not determine the rowcount for some type
new primary key identifiers for each new object; internally it normally uses
the same :attr:`_engine.CursorResult.inserted_primary_key` accessor we
introduced previously. The ``squidward`` and ``krabs`` objects now have these new
-primary key identifiers associated with them and we can view them by acesssing
+primary key identifiers associated with them and we can view them by accessing
the ``id`` attribute::
>>> squidward.id
projects / thirdparty / sqlalchemy / sqlalchemy.git / commitdiff
