when True indicates that the Python ``None`` value should be
persisted as SQL NULL, rather than JSON-encoded ``'null'``.
- Retrival of NULL as None is also repaired for DBAPIs other than
+ Retrieval of NULL as None is also repaired for DBAPIs other than
psycopg2, namely pg8000.
.. change::
Added new argument ``include_backrefs=True`` to the
:func:`.validates` function; when set to False, a validation event
- will not be triggered if the event was initated as a backref to
+ will not be triggered if the event was initiated as a backref to
an attribute operation from the other side.
.. seealso::
.. change::
:tags: bug, mssql
- :tickes: 3791
+ :tickets: 3791
:versions: 1.1.0
Added error code 20017 "unexpected EOF from the server" to the list of
Removing (or adding) an event listener at the same time that the event
is being run itself, either from inside the listener or from a
concurrent thread, now raises a RuntimeError, as the collection used is
- now an instance of ``colletions.deque()`` and does not support changes
+ now an instance of ``collections.deque()`` and does not support changes
while being iterated. Previously, a plain Python list was used where
removal from inside the event itself would produce silent failures.
.. change:: 3882
:tags: bug, sql
- :tikets: 3882
+ :tickets: 3882
Fixed bug originally introduced in 0.9 via :ticket:`1068` where
order_by(<some Label()>) would order by the label name based on name
.. change::
:tags: bug, orm
- :tickests: 4400
+ :tickets: 4400
Fixed bug where chaining of mapper options using
:meth:`.RelationshipProperty.of_type` in conjunction with a chained option
Fixed issue where by if the "begin" of a transaction failed at the Core
engine/connection level, such as due to network error or database is locked
for some transactional recipes, within the context of the :class:`.Session`
- procuring that connection from the conneciton pool and then immediately
+ procuring that connection from the connection pool and then immediately
returning it, the ORM :class:`.Session` would not close the connection
despite this connection not being stored within the state of that
:class:`.Session`. This would lead to the connection being cleaned out by
by table name only without the column names would not correctly be
reflected as far as setting up the "referred columns", since SQLite's
PRAGMA does not report on these columns if they weren't given explicitly.
- For some reason this was harcoded to assume the name of the local column,
+ For some reason this was hardcoded to assume the name of the local column,
which might work for some cases but is not correct. The new approach
reflects the primary key of the referred table and uses the constraint
columns list as the referred columns list, if the remote column(s) aren't
Added support for reflection of CHECK constraints that include the special
PostgreSQL qualifier "NOT VALID", which can be present for CHECK
- constraints that were added to an exsiting table with the directive that
+ constraints that were added to an existing table with the directive that
they not be applied to existing data in the table. The PostgreSQL
dictionary for CHECK constraints as returned by
:meth:`_reflection.Inspector.get_check_constraints` may include an additional entry
The dialects that support json are supposed to take arguments
``json_serializer`` and ``json_deserializer`` at the create_engine() level,
- however the SQLite dialect calls them ``_json_serilizer`` and
+ however the SQLite dialect calls them ``_json_serializer`` and
``_json_deserilalizer``. The names have been corrected, the old names are
accepted with a change warning, and these parameters are now documented as
:paramref:`_sa.create_engine.json_serializer` and
Fixed an unlikely issue where the "corresponding column" routine for unions
and other :class:`_selectable.CompoundSelect` objects could return the wrong column in
- some overlapping column situtations, thus potentially impacting some ORM
+ some overlapping column situations, thus potentially impacting some ORM
operations when set operations are in use, if the underlying
:func:`_expression.select` constructs were used previously in other similar kinds of
routines, due to a cached value not being cleared.
:tags: bug, orm, py3k
:tickets: 4674
- Replaced the Python compatbility routines for ``getfullargspec()`` with a
+ Replaced the Python compatibility routines for ``getfullargspec()`` with a
fully vendored version from Python 3.3. Originally, Python was emitting
deprecation warnings for this function in Python 3.8 alphas. While this
change was reverted, it was observed that Python 3 implementations for
:tickets: 4695
Fixed issue where the :paramref:`.AttributeEvents.active_history` flag
- would not be set for an event listener that propgated to a subclass via the
+ would not be set for an event listener that propagated to a subclass via the
:paramref:`.AttributeEvents.propagate` flag. This bug has been present
for the full span of the :class:`.AttributeEvents` system.
fully, and more importantly, by default. However, the conditions under which a
particular DBAPI would or would not return Unicode data from a result, as well
as accept Python Unicode values as parameters, remained extremely complicated.
-This was the beginning of the obsolesence of the "convert_unicode" flags,
+This was the beginning of the obsolescence of the "convert_unicode" flags,
because they were no longer sufficient as a means of ensuring that
encode/decode was occurring only where needed and not where it wasn't needed.
Instead, "convert_unicode" started to be automatically detected by dialects.
SQLAlchemy has long had a behavior of cascading objects into the
:class:`_orm.Session` based on backref assignment. Given ``User`` below
already in a :class:`_orm.Session`, assigning it to the ``Address.user``
-attribute of an ``Address`` object, assuming a bidrectional relationship
+attribute of an ``Address`` object, assuming a bidirectional relationship
is set up, would mean that the ``Address`` also gets put into the
:class:`_orm.Session` at that point::
dialect will now retrieve this list if the given :func:`_sql.insert` construct
requests returning via the :meth:`.Insert.returning` method or similar methods
intended to return generated defaults; the rows are then installed in the
-result so that they are retreieved as though they came from the cursor
+result so that they are retrieved as though they came from the cursor
directly. This allows tools like the ORM to use batched inserts in all cases,
which is expected to provide a dramatic performance improvement.
* RETURNING support is enabled for ``"values_only"`` and ``"values"`` for
INSERT statements. The psycopg2 dialect will receive the rows back
from psycopg2 using the fetch=True flag and install them into the result
- set as though they came directly from the cursor (which they ulimately did,
+ set as though they came directly from the cursor (which they ultimately did,
however psycopg2's extension function has aggregated multiple batches into
one list).
The MySQL dialect will render FROM DUAL for a SELECT statement that has no
FROM clause but has a WHERE clause. This allows things like "SELECT 1 WHERE
- EXISTS (subuqery)" kinds of queries to be used as well as other use cases.
+ EXISTS (subquery)" kinds of queries to be used as well as other use cases.
:tags: bug, orm
:tickets: 5074
- The :class:`.Session` object no longer initates a
+ The :class:`.Session` object no longer initiates a
:class:`.SessionTransaction` object immediately upon construction or after
the previous transaction is closed; instead, "autobegin" logic now
initiates the new :class:`.SessionTransaction` on demand when it is next
.. change::
- :tags: peformance, postgresql
+ :tags: performance, postgresql
:tickets: 5401
The psycopg2 dialect now defaults to using the very performant
``execute_values()`` psycopg2 extension for compiled INSERT statements,
- and also impements RETURNING support when this extension is used. This
+ and also implements RETURNING support when this extension is used. This
allows INSERT statements that even include an autoincremented SERIAL
or IDENTITY value to run very fast while still being able to return the
newly generated primary key values. The ORM will then integrate this
Instead, each statement invoked upon the connection will commit any changes
automatically; it sometimes also means that the connection itself will use
fewer server-side database resources. For this reason and others, "autocommit"
-mode is often desirable for non-tranasctional applications that need to read
+mode is often desirable for non-transactional applications that need to read
individual tables or rows in isolation of a true ACID transaction.
SQLAlchemy dialects can support these isolation levels as well as autocommit to
For example, to force REPEATABLE READ on a specific connection::
- with engine.connect().execution_options(isolation_level="REPEATBLE READ") as connection:
+ with engine.connect().execution_options(isolation_level="REPEATABLE READ") as connection:
connection.execute(<statement>)
The :paramref:`_engine.Connection.execution_options.isolation_level` option
name: wendy ; fullname: Wendy Williams
To access columns via name using strings, either when the column name is
-progammatically generated, or contains non-ascii characters, the
+programmatically generated, or contains non-ascii characters, the
:attr:`.Row._mapping` view may be used that provides dictionary-like access:
.. sourcecode:: pycon+sql
:class:`_schema.MetaData` object that in turn allows objects like the ORM
:class:`_orm.Session` to associate a particular mapped class with an
:class:`_orm.Engine`. In SQLAlchemy 2.0, the :class:`_orm.Session` must be
-linked to each :class:`_orm.Engine` directly. That is, instead of instantating
+linked to each :class:`_orm.Engine` directly. That is, instead of instantiating
the :class:`_orm.Session` or
:class:`_orm.sessionmaker` without any arguments, and associating the
:class:`_engine.Engine` with the :class:`_schema.MetaData`::
---------------------------------------------------------------------------------------------------------------------------------------------
-This error is emited when the :paramref:`_orm.relationship.single_parent` flag
+This error is emitted when the :paramref:`_orm.relationship.single_parent` flag
is used, and more than one object is assigned as the "parent" of an object at
once.
SQLAlchemy Core which will behave differently when used in an ORM
context.
- SQLAlchemy allows Core consrtucts such as :class:`_sql.Select` objects
+ SQLAlchemy allows Core constructs such as :class:`_sql.Select` objects
to participate in a "plugin" system, which can inject additional
behaviors and features into the object that are not present by default.
Above, when a ``Parent`` object is marked for deletion
using :meth:`_orm.Session.delete`, the flush process will as usual delete
-the assocation rows from the ``association`` table, however per cascade
+the associated rows from the ``association`` table, however per cascade
rules it will also delete all related ``Child`` rows.
:class:`.sessionmaker` factory should be globally scoped, the same way as
the :class:`_engine.Engine` object created by :func:`_sa.create_engine` is
also typically globally scoped. As these objects are both factories, they
-can be used by any number of functions and threads simultaenously.
+can be used by any number of functions and threads simultaneously.
.. seealso::
may be used::
session.query(User).filter(User.nane == "squidward").\
- update({"name": "spongebob"}, syncronize_session="fetch")
+ update({"name": "spongebob"}, synchronize_session="fetch")
Above, an UPDATE will be emitted against all rows that match the name
"squidward" and be updated to the name "spongebob". The
from sqlalchemy import update
stmt = update(User).where(User.nane == "squidward").values(name="spongebob")).\
- execution_options(syncronize_session="fetch")
+ execution_options(synchronize_session="fetch")
session.execute(stmt)
Bulk delete, :term:`1.x style`::
session.query(User).filter(User.nane == "squidward").\
- delete(syncronize_session="fetch")
+ delete(synchronize_session="fetch")
Bulk delete, :term:`2.0 style`. The :meth:`_orm.Session` must
be configured with :paramref:`_orm.Session.future` set to ``True``::
session = Session(future=True)
from sqlalchemy import delete
- stmt = delete(User).where(User.nane == "squidward").execution_options(syncronize_session="fetch")
+ stmt = delete(User).where(User.nane == "squidward").execution_options(synchronize_session="fetch")
session.execute(stmt)
The bulk UPDATE and DELETE features bypass ORM unit-of-work automation in
favor being able to emit a single UPDATE or DELETE statement at once
- without complextiy.
+ without complexity.
* The operations do not offer in-Python cascading of
relationships - it is assumed that ON UPDATE CASCADE and/or
use the same sequence of steps to begin the transaction. This includes
that the :meth:`_orm.SessionEvents.after_transaction_create` event is invoked
when it occurs; this hook is used by frameworks in order to integrate their
-own trasactional processes with that of the ORM :class:`_orm.Session`.
+own transactional processes with that of the ORM :class:`_orm.Session`.
.. _session_subtransactions:
The "subtransaction" pattern that was often used with autocommit mode is
also deprecated in 1.4. This pattern allowed the use of the
-:meth:`_orm.Session.begin` method when a tranasction were already begun,
+:meth:`_orm.Session.begin` method when a transaction were already begun,
resulting in a construct called a "subtransaction", which was essentially
a block that would prevent the :meth:`_orm.Session.commit` method from actually
committing.
.. versionadded:: 1.3.16 added support for AUTOCOMMIT to the cx_oracle dialect
- as well as the notion of a default isolation level, currently harcoded
+ as well as the notion of a default isolation level, currently hardcoded
to "READ COMMITTED".
.. seealso::
In this calling form, the expression renders an "empty set"
expression. These expressions are tailored to individual backends
and are generaly trying to get an empty SELECT statement as a
- subuqery. Such as on SQLite, the expression is::
+ subquery. Such as on SQLite, the expression is::
WHERE col IN (SELECT 1 FROM (SELECT 1) WHERE 1!=1)
projects / thirdparty / sqlalchemy / sqlalchemy.git / commitdiff
