:released: April 30, 2015
.. change::
:tags: bug, orm, pypy
:tickets: 3405
Fixed regression from 0.9.10 prior to release due to :ticket:`3349`
where the check for query state on :meth:`_query.Query.update` or
:meth:`_query.Query.delete` compared the empty tuple to itself using ``is``,
which fails on PyPy to produce ``True`` in this case; this would
erroneously emit a warning in 0.9 and raise an exception in 1.0.
.. change::
:tags: feature, engine
:tickets: 3379
New features added to support engine/pool plugins with advanced
functionality. Added a new "soft invalidate" feature to the
connection pool at the level of the checked out connection wrapper
as well as the :class:`._ConnectionRecord`. This works similarly
to a modern pool invalidation in that connections aren't actively
closed, but are recycled only on next checkout; this is essentially
a per-connection version of that feature. A new event
:meth:`_events.PoolEvents.soft_invalidate` is added to complement it.
Also added new flag
:attr:`.ExceptionContext.invalidate_pool_on_disconnect`.
Allows an error handler within :meth:`_events.ConnectionEvents.handle_error`
to maintain a "disconnect" condition, but to handle calling invalidate
on individual connections in a specific manner within the event.
.. change::
:tags: feature, engine
:tickets: 3355
Added new event :class:`.DialectEvents.do_connect`, which allows
interception / replacement of when the :meth:`.Dialect.connect`
hook is called to create a DBAPI connection. Also added
dialect plugin hooks :meth:`.Dialect.get_dialect_cls` and
:meth:`.Dialect.engine_created` which allow external plugins to
add events to existing dialects using entry points.
.. change::
:tags: bug, orm
:tickets: 3403, 3320
Fixed regression from 0.9.10 prior to release where the new addition
of ``entity`` to the :attr:`_query.Query.column_descriptions` accessor
would fail if the target entity was produced from a core selectable
such as a :class:`_schema.Table` or :class:`_expression.CTE` object.
.. change::
:tags: feature, sql
Added a placeholder method :meth:`.TypeEngine.compare_against_backend`
which is now consumed by Alembic migrations as of 0.7.6. User-defined
types can implement this method to assist in the comparison of
a type against one reflected from the database.
.. change::
:tags: bug, orm
:tickets: 3402
Fixed regression within the flush process when an attribute were
set to a SQL expression for an UPDATE, and the SQL expression when
compared to the previous value of the attribute would produce a SQL
comparison other than ``==`` or ``!=``, the exception "Boolean value
of this clause is not defined" would raise. The fix ensures that
the unit of work will not interpret the SQL expression in this way.
.. change::
:tags: bug, ext
:tickets: 3397
Fixed bug in association proxy where an any()/has()
on an relationship->scalar non-object attribute comparison would fail,
e.g.
``filter(Parent.some_collection_to_attribute.any(Child.attr == 'foo'))``
.. change::
:tags: bug, sql
:tickets: 3396
Fixed bug where the truncation of long labels in SQL could produce
a label that overlapped another label that is not truncated; this
because the length threshold for truncation was greater than
the portion of the label that remains after truncation. These
two values have now been made the same; label_length - 6.
The effect here is that shorter column labels will be "truncated"
where they would not have been truncated before.
.. change::
:tags: bug, orm
:tickets: 3392
Fixed unexpected use regression due to :ticket:`2992` where
textual elements placed
into the :meth:`_query.Query.order_by` clause in conjunction with joined
eager loading would be added to the columns clause of the inner query
in such a way that they were assumed to be table-bound column names,
in the case where the joined eager load needs to wrap the query
in a subquery to accommodate for a limit/offset.
Originally, the behavior here was intentional, in that a query such
as ``query(User).order_by('name').limit(1)``
would order by ``user.name`` even if the query was modified by
joined eager loading to be within a subquery, as ``'name'`` would
be interpreted as a symbol to be located within the FROM clauses,
in this case ``User.name``, which would then be copied into the
columns clause to ensure it were present for ORDER BY. However, the
feature fails to anticipate the case where ``order_by("name")`` refers
to a specific label name present in the local columns clause already
and not a name bound to a selectable in the FROM clause.
Beyond that, the feature also fails for deprecated cases such as
``order_by("name desc")``, which, while it emits a
warning that :func:`_expression.text` should be used here (note that the issue
does not impact cases where :func:`_expression.text` is used explicitly),
still produces a different query than previously where the "name desc"
expression is copied into the columns clause inappropriately. The
resolution is such that the "joined eager loading" aspect of the
feature will skip over these so-called "label reference" expressions
when augmenting the inner columns clause, as though they were
:func:`_expression.text` constructs already.
.. change::
:tags: bug, sql
:tickets: 3391
Fixed regression due to :ticket:`3282` where the ``tables`` collection
passed as a keyword argument to the :meth:`.DDLEvents.before_create`,
:meth:`.DDLEvents.after_create`, :meth:`.DDLEvents.before_drop`, and
:meth:`.DDLEvents.after_drop` events would no longer be a list
of tables, but instead a list of tuples which contained a second
entry with foreign keys to be added or dropped. As the ``tables``
collection, while documented as not necessarily stable, has come
to be relied upon, this change is considered a regression.
Additionally, in some cases for "drop", this collection would
be an iterator that would cause the operation to fail if
prematurely iterated. The collection is now a list of table
objects in all cases and test coverage for the format of this
collection is now added.
.. change::
:tags: bug, orm
:tickets: 3388
Fixed a regression regarding the :meth:`.MapperEvents.instrument_class`
event where its invocation was moved to be after the class manager's
instrumentation of the class, which is the opposite of what the
documentation for the event explicitly states. The rationale for the
switch was due to Declarative taking the step of setting up
the full "instrumentation manager" for a class before it was mapped
for the purpose of the new ``declared_attr`` features
described in :ref:`feature_3150`, but the change was also made
against the classical use of :class:`_orm.Mapper` for consistency.
However, SQLSoup relies upon the instrumentation event happening
before any instrumentation under classical mapping.
The behavior is reverted in the case of classical and declarative
mapping, the latter implemented by using a simple memoization
without using class manager.
.. change::
:tags: bug, orm
:tickets: 3387
Fixed issue in new :meth:`.QueryEvents.before_compile` event where
changes made to the :class:`_query.Query` object's collection of entities
to load within the event would render in the SQL, but would not
be reflected during the loading process.
.. changelog::