Skip to content

1.3.12

Compare
Choose a tag to compare
@sqla-tester sqla-tester released this 16 Dec 18:43

1.3.12

Released: December 16, 2019

orm

  • [orm] [bug] Fixed issue involving lazy="raise" strategy where an ORM delete of an
    object would raise for a simple "use-get" style many-to-one relationship
    that had lazy="raise" configured. This is inconsistent vs. the change
    introduced in 1.3 as part of #4353, where it was established that
    a history operation that does not expect emit SQL should bypass the
    lazy="raise" check, and instead effectively treat it as
    lazy="raise_on_sql" for this case. The fix adjusts the lazy loader
    strategy to not raise for the case where the lazy load was instructed that
    it should not emit SQL if the object were not present.

    References: #4997

  • [orm] [bug] Fixed regression introduced in 1.3.0 related to the association proxy
    refactor in #4351 that prevented composite() attributes
    from working in terms of an association proxy that references them.

    References: #5000

  • [orm] [bug] Setting persistence-related flags on relationship() while also
    setting viewonly=True will now emit a regular warning, as these flags do
    not make sense for a viewonly=True relationship. In particular, the
    "cascade" settings have their own warning that is generated based on the
    individual values, such as "delete, delete-orphan", that should not apply
    to a viewonly relationship. Note however that in the case of "cascade",
    these settings are still erroneously taking effect even though the
    relationship is set up as "viewonly". In 1.4, all persistence-related
    cascade settings will be disallowed on a viewonly=True relationship in
    order to resolve this issue.

    References: #4993

  • [orm] [bug] [py3k] Fixed issue where when assigning a collection to itself as a slice, the
    mutation operation would fail as it would first erase the assigned
    collection inadvertently. As an assignment that does not change the
    contents should not generate events, the operation is now a no-op. Note
    that the fix only applies to Python 3; in Python 2, the __setitem__
    hook isn't called in this case; __setslice__ is used instead which
    recreates the list item-by-item in all cases.

    References: #4990

  • [orm] [bug] 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 Session
    procuring that connection from the conneciton pool and then immediately
    returning it, the ORM Session would not close the connection
    despite this connection not being stored within the state of that
    Session. This would lead to the connection being cleaned out by
    the connection pool weakref handler within garbage collection which is an
    unpreferred codepath that in some special configurations can emit errors in
    standard error.

    References: #5034

sql

  • [sql] [bug] Fixed bug where "distinct" keyword passed to select() would not
    treat a string value as a "label reference" in the same way that the
    select.distinct() does; it would instead raise unconditionally. This
    keyword argument and the others passed to select() will ultimately
    be deprecated for SQLAlchemy 2.0.

    References: #5028

  • [sql] [bug] Changed the text of the exception for "Can't resolve label reference" to
    include other kinds of label coercions, namely that "DISTINCT" is also in
    this category under the PostgreSQL dialect.

sqlite

  • [sqlite] [bug] Fixed issue to workaround SQLite's behavior of assigning "numeric" affinity
    to JSON datatypes, first described at change_3850, which returns
    scalar numeric JSON values as a number and not as a string that can be JSON
    deserialized. The SQLite-specific JSON deserializer now gracefully
    degrades for this case as an exception and bypasses deserialization for
    single numeric values, as from a JSON perspective they are already
    deserialized.

    References: #5014

mssql

  • [mssql] [bug] Repaired support for the mssql.DATETIMEOFFSET datatype on PyODBC,
    by adding PyODBC-level result handlers as it does not include native
    support for this datatype. This includes usage of the Python 3 "timezone"
    tzinfo subclass in order to set up a timezone, which on Python 2 makes
    use of a minimal backport of "timezone" in sqlalchemy.util.

    References: #4983