the bytes() callable when run on Python 3; in particular
psycopg2 2.5 with Python 3.3 seems to now be returning
the "memoryview" type, so this is converted to bytes
before return.
handling. If a non-disconnect error occurs,
but leads to a delayed disconnect error within error
handling (happens with MySQL), the disconnect condition
is detected. The Connection can now also be closed
when in an invalid state, meaning it will raise "closed"
on next usage, and additionally the "close with result"
feature will work even if the autorollback in an error
handling routine fails and regardless of whether the
condition is a disconnect or not.
[ticket:2695]
labeled columns when apply_labels() is used; this mode
produces a SELECT where each column is labeled as in
<tablename>_<columnname>, to remove column name collisions
for a multiple table select. The fix is that if two labels
collide when combined with the table name, i.e.
"foo.bar_id" and "foo_bar.id", anonymous aliasing will be
applied to one of the dupes. This allows the ORM to handle
both columns independently; previously, 0.7
would in some cases silently emit a second SELECT for the
column that was "duped", and in 0.8 an ambiguous column error
would be emitted. The "keys" applied to the .c. collection
of the select() will also be deduped, so that the "column
being replaced" warning will no longer emit for any select()
that specifies use_labels, though the dupe key will be given
an anonymous label which isn't generally user-friendly.
[ticket:2702]
where since it considers the current class' ``__table__``, was
sensitive to when it was called. This is 0.7's behavior also,
but in 0.7 things tended to "work out" within events like
``__mapper_args__()``. :func:`.has_inherited_table` now only
considers superclasses, so should return the same answer
regarding the current class no matter when it's called
(obviously assuming the state of the superclass).
[ticket:2656]
``query(SubClass).options(subqueryload(Baseclass.attrname))``,
where ``SubClass`` is a joined inh of ``BaseClass``,
would fail to apply the ``JOIN`` inside the subquery
on the attribute load, producing a cartesian product.
The populated results still tended to be correct as additional
rows are just ignored, so this issue may be present as a
performance degradation in applications that are
otherwise working correctly. [ticket:2699]
subclass could insert the row for the "sub" table
before the parent table, if the two tables had no
ForeignKey constraints set up between them.
Also in 0.7.11. [ticket:2689]
- fix a glitch in the assertsql.CompiledSQL fixture regarding
when a multiparam compiledSQL is used within an AllOf
- add a new utility function randomize_unitofwork() which
does the function of --reversetop
passed to Table(); since we want to support external dialects
and also want to support args without a certain dialect
being installed, it only checks the format of the arg now,
rather than looking for that dialect in sqlalchemy.dialects.
Mike Bayer