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.
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.
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
---------------------------------------------------------------------------------------------------------------------------------------------
-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.
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.
.. 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::
projects / thirdparty / sqlalchemy / sqlalchemy.git / commitdiff
