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