github sqlalchemy/sqlalchemy rel_1_1_0b2
v1.1.0b2

1.1.0b2

Released: July 1, 2016

sql

  • [sql] [bug] Fixed issue in SQL math negation operator where the type of the
    expression would no longer be the numeric type of the original.
    This would cause issues where the type determined result set
    behaviors.

    This change is also backported to: 1.0.14

    References: #3735

  • [sql] [bug] Fixed bug whereby the __getstate__ / __setstate__
    methods for sqlalchemy.util.Properties were
    non-working due to the transition in the 1.0 series to __slots__.
    The issue potentially impacted some third-party applications.
    Pull request courtesy Pieter Mulder.

    This change is also backported to: 1.0.14

    References: #3728

  • [sql] [bug] The processing performed by the Boolean datatype for backends
    that only feature integer types has been made consistent between the
    pure Python and C-extension versions, in that the C-extension version
    will accept any integer value from the database as a boolean, not just
    zero and one; additionally, non-boolean integer values being sent to
    the database are coerced to exactly zero or one, instead of being
    passed as the original integer value.

    References: #3730

  • [sql] [bug] Rolled back the validation rules a bit in Enum to allow
    unknown string values to pass through, unless the flag
    validate_string=True is passed to the Enum; any other kind of object is
    still of course rejected. While the immediate use
    is to allow comparisons to enums with LIKE, the fact that this
    use exists indicates there may be more unknown-string-comparison use
    cases than we expected, which hints that perhaps there are some
    unknown string-INSERT cases too.

    References: #3725

postgresql

  • [postgresql] [bug] [ext] Made a slight behavioral change in the sqlalchemy.ext.compiler
    extension, whereby the existing compilation schemes for an established
    construct would be removed if that construct itself didn't already
    have its own dedicated __visit_name__. This was a
    rare occurrence in 1.0, however in 1.1 postgresql.ARRAY
    subclasses sqltypes.ARRAY and has this behavior.
    As a result, setting up a compilation handler for another dialect
    such as SQLite would render the main postgresql.ARRAY
    object no longer compilable.

    References: #3732

mysql

  • [mysql] [bug] Dialed back the "order the primary key columns per auto-increment"
    described in change_mysql_3216 a bit, so that if the
    PrimaryKeyConstraint is explicitly defined, the order
    of columns is maintained exactly, allowing control of this behavior
    when necessary.

    References: #3726

latest releases: rel_1_3_20, rel_1_3_19, rel_1_3_18...
pre-release13 months ago