1.3.4

Released: May 27, 2019

• [feature] [mssql] Added support for SQL Server filtered indexes, via the mssql_where
  parameter which works similarly to that of the postgresql_where index
  function in the PostgreSQL dialect.

  References: #4657

• [bug] [misc] Removed errant "sqla_nose.py" symbol from MANIFEST.in which created an
  undesirable warning message.

  References: #4625

• [bug] [sql] Fixed that the GenericFunction class was inadvertently
  registering itself as one of the named functions. Pull request courtesy
  Adrien Berchet.

  References: #4653

• [bug] [engine] [postgresql] Moved the "rollback" which occurs during dialect initialization so that it
  occurs after additional dialect-specific initialize steps, in particular
  those of the psycopg2 dialect which would inadvertently leave transactional
  state on the first new connection, which could interfere with some
  psycopg2-specific APIs which require that no transaction is started. Pull
  request courtesy Matthew Wilkes.

  References: #4663

• [bug] [orm] Fixed issue where the AttributeEvents.active_history flag
  would not be set for an event listener that propgated to a subclass via the
  AttributeEvents.propagate flag. This bug has been present
  for the full span of the AttributeEvents system.

  References: #4695

• [bug] [orm] Fixed regression where new association proxy system was still not proxying
  hybrid attributes when they made use of the @hybrid_property.expression
  decorator to return an alternate SQL expression, or when the hybrid
  returned an arbitrary PropComparator, at the expression level.
  This involved further generalization of the heuristics used to detect the
  type of object being proxied at the level of QueryableAttribute,
  to better detect if the descriptor ultimately serves mapped classes or
  column expressions.

  References: #4690

• [bug] [orm] Applied the mapper "configure mutex" against the declarative class mapping
  process, to guard against the race which can occur if mappers are used
  while dynamic module import schemes are still in the process of configuring
  mappers for related classes. This does not guard against all possible race
  conditions, such as if the concurrent import has not yet encountered the
  dependent classes as of yet, however it guards against as much as possible
  within the SQLAlchemy declarative process.

  References: #4686

• [bug] [mssql] Added error code 20047 to "is_disconnect" for pymssql. Pull request
  courtesy Jon Schuff.

  References: #4680

• [bug] [orm] [postgresql] Fixed an issue where the "number of rows matched" warning would emit even if
  the dialect reported "supports_sane_multi_rowcount=False", as is the case
  for psycogp2 with use_batch_mode=True and others.

  References: #4661

• [bug] [sql] Fixed issue where double negation of a boolean column wouldn't reset
  the "NOT" operator.

  References: #4618

• [bug] [mysql] Added support for DROP CHECK constraint which is required by MySQL 8.0.16
  to drop a CHECK constraint; MariaDB supports plain DROP CONSTRAINT. The
  logic distinguishes between the two syntaxes by checking the server version
  string for MariaDB presence. Alembic migrations has already worked
  around this issue by implementing its own DROP for MySQL / MariaDB CHECK
  constraints, however this change implements it straight in Core so that its
  available for general use. Pull request courtesy Hannes Hansen.

  References: #4650

• [bug] [orm] A warning is now emitted for the case where a transient object is being
  merged into the session with Session.merge() when that object is
  already transient in the Session. This warns for the case where
  the object would normally be double-inserted.

  References: #4647

• [bug] [orm] Fixed regression in new relationship m2o comparison logic first introduced
  at change_4359 when comparing to an attribute that is persisted as
  NULL and is in an un-fetched state in the mapped instance. Since the
  attribute has no explicit default, it needs to default to NULL when
  accessed in a persistent setting.

  References: #4676

• [bug] [sql] The GenericFunction namespace is being migrated so that function
  names are looked up in a case-insensitive manner, as SQL functions do not
  collide on case sensitive differences nor is this something which would
  occur with user-defined functions or stored procedures. Lookups for
  functions declared with GenericFunction now use a case
  insensitive scheme, however a deprecation case is supported which allows
  two or more GenericFunction objects with the same name of
  different cases to exist, which will cause case sensitive lookups to occur
  for that particular name, while emitting a warning at function registration
  time. Thanks to Adrien Berchet for a lot of work on this complicated
  feature.

  References: #4569