0.6.2

0.6.2

Released: Fri Dec 27 2013

• [bug] Autogenerate for op.create_table() will not include a
  PrimaryKeyConstraint() that has no columns.

• [bug] Fixed bug in the not-internally-used ScriptDirectory.get_base()
  method which would fail if called on an empty versions directory.

• [bug] An almost-rewrite of the new unique constraint/index autogenerate
  detection, to accommodate a variety of issues. The emphasis is on
  not generating false positives for those cases where no net change
  is present, as these errors are the ones that impact all autogenerate
  runs:

  -   Fixed an issue with unique constraint autogenerate detection where
      a named `UniqueConstraint` on both sides with column changes would
      render with the "add" operation before the "drop", requiring the
      user to reverse the order manually.
  
  -   Corrected for MySQL's apparent addition of an implicit index
      for a foreign key column, so that it doesn't show up as "removed".
      This required that the index/constraint autogen system query the
      dialect-specific implementation for special exceptions.
  
  -   reworked the "dedupe" logic to accommodate MySQL's bi-directional
      duplication of unique indexes as unique constraints, and unique
      constraints as unique indexes.  Postgresql's slightly different
      logic of duplicating unique constraints into unique indexes
      continues to be accommodated as well.  Note that a unique index
      or unique constraint removal on a backend that duplicates these may
      show up as a distinct "remove_constraint()" / "remove_index()" pair,
      which may need to be corrected in the post-autogenerate if multiple
      backends are being supported.
  
  -   added another dialect-specific exception to the SQLite backend
      when dealing with unnamed unique constraints, as the backend can't
      currently report on constraints that were made with this technique,
      hence they'd come out as "added" on every run.
  
  -   the `op.create_table()` directive will be auto-generated with
      the `UniqueConstraint` objects inline, but will not double them
      up with a separate `create_unique_constraint()` call, which may
      have been occurring.  Indexes still get rendered as distinct
      `op.create_index()` calls even when the corresponding table was
      created in the same script.
  
  -   the inline `UniqueConstraint` within `op.create_table()` includes
      all the options like `deferrable`, `initially`, etc.  Previously
      these weren't rendering.
  

  References: #157

• [feature] [mssql] Added new argument mssql_drop_foreign_key to
  Operations.drop_column(). Like mssql_drop_default
  and mssql_drop_check, will do an inline lookup for a
  single foreign key which applies to this column, and drop it.
  For a column with more than one FK, you'd still need to explicitly
  use Operations.drop_constraint() given the name,
  even though only MSSQL has this limitation in the first place.

• [bug] [mssql] The MSSQL backend will add the batch separator (e.g. "GO")
  in --sql mode after the final COMMIT statement, to ensure
  that statement is also processed in batch mode. Courtesy
  Derek Harland.