0.7.7

- fix this name for the 0.7 branch

- Fixed critical issue where a complex series of branches/merges would
bog down the iteration algorithm working over redundant nodes for
millions of cycles.   An internal adjustment has been
made so that duplicate nodes are skipped within this iteration.
fixes #310

- Implemented support for :meth:`.BatchOperations.create_primary_key`
and :meth:`.BatchOperations.create_check_constraint`.
fixes #305
- table keyword arguments are copied from the original reflected table,
such as the "mysql_engine" keyword argument.

- add a changelog for the legacy_schema_aliasing warning issue,
the fix was committed in 229f8672.

- add clarification that this tutorial is against the generic template

- The :meth:`.MigrationContext.stamp` method, added as part of the
versioning refactor in 0.7 as a more granular version of
:func:`.command.stamp`, now includes the "create the alembic_version
table if not present" step in the same way as the command version,
which was previously omitted.
fixes #300

- turn on the mssql legacy_schema_aliasing flag to remove
warnings

- Fixed bug where foreign key options including "onupdate",
"ondelete" would not render within the ``op.create_foreign_key()``
directive, even though they render within a full
``ForeignKeyConstraint`` directive.
fixes #298

- add test for FKC with multiple kwargs, reference #92

0.7.6

Merged in jdanjou/alembic/jd/typo-doc-comparator (pull request #44)

Fix typo in autogenerate documentation

Fix typo in autogenerate documentation

- Fixed bug where the case of multiple mergepoints that all
have the identical set of ancestor revisions would fail to be
upgradable, producing an assertion failure.   Merge points were
previously assumed to always require at least an UPDATE in
alembic_revision from one of the previous revs to the new one,
however in this case, if one of the mergepoints has already
been reached, the remaining mergepoints have no row to UPDATE therefore
they must do an INSERT of their target version.
fixes #297

- add tox targets for 3.4

- Added support for type comparison functions to be not just per
environment, but also present on the custom types themselves, by
supplying a method ``compare_against_backend``.
Added a new documentation section :ref:`compare_types` describing
type comparison fully.
fixes #296

Merged in rtaranu/alembic (pull request #43)

- fixed spelling mistake in docs

- fixed spelling mistake in docs

- Added a new option
:paramref:`.EnvironmentContext.configure.literal_binds`, which
will pass the ``literal_binds`` flag into the compilation of SQL
constructs when using "offline" mode.  This has the effect that
SQL objects like inserts, updates, deletes as well as textual
statements sent using ``text()`` will be compiled such that the dialect
will attempt to render literal values "inline" automatically.
Only a subset of types is typically supported; the
:meth:`.Operations.inline_literal` construct remains as the construct
used to force a specific literal representation of a value.
The :paramref:`.EnvironmentContext.configure.literal_binds` flag
is added to the "offline" section of the ``env.py`` files generated
in new environments.
fixes #255
- enhance the op_fixture as well as MigrationContext._stdout_connection()
 so that it uses the real DefaultImpl
and MigrationContext fully in tests.

- repair name of starting_rev argument, fixes #290

- dont rely on inpsect import, not in SQLA 0.7

- don't use op.f(), only works with later SQLA versions

- Fully implemented the
:paramref:`~.Operations.batch_alter_table.copy_from` parameter for
batch mode, which previously was not functioning.  This allows
"batch mode" to be usable in conjunction with ``--sql``.
fixes #289
- sqlite dialect checks for "create_index" and "drop_index" as exceptions
for "recreate" in batch mode, the same way as "add_column", so that
unnecessary table recreates don't emit for index-only operations

- next version

- Repaired support for the :meth:`.BatchOperations.create_index`
directive, which was mis-named internally such that the operation
within a batch context could not proceed.
fixes #287

- didn't name the internal number correctly, stil
don't have this right.  up to post2

- 0.7.5.post1 due to pypi deletion issue

0.7.5

- changelog for #266
- use exception fixture
- look directly at context.as_sql as that's where
the "sql mode" is most authoritative
- fixes #266

Merge branch 'issue266' of https://bitbucket.org/jerdfelt/alembic into pr39

- Fixed bug where the mssql DROP COLUMN directive failed to include
modifiers such as "schema" when emitting the DDL.
fixes #284

- an adjustment to the logic for #282 - if the index we see here
*is* in conn_indexes_by_name, then obviously we should leave it in.

- Postgresql "functional" indexes are necessarily skipped from the
autogenerate process, as the SQLAlchemy backend currently does not
support reflection of these structures.   A warning is emitted
both from the SQLAlchemy backend as well as from the Alembic
backend for Postgresql when such an index is detected.
fixes #282

- add support for assertion of warnings emitted

- make the repo dynamic

Raise exception if autogenerate is tried with as_sql=True

This configuration is nonsensical since autogenerate needs to query
the database for schema information.

Fixes issue #266

- Fixed bug where MySQL backend would report dropped unique indexes
and/or constraints as both at the same time.  This is because
MySQL doesn't actually have a "unique constraint" construct that
reports differently than a "unique index", so it is present in both
lists.  The net effect though is that the MySQL backend will report
a dropped unique index/constraint as an index in cases where the object
was first created as a unique constraint, if no other information
is available to make the decision.  This differs from other backends
like Postgresql which can report on unique constraints and
unique indexes separately.
fixes #276

- additional fix which impacts #267.  fix filtered_heads() to accommodate
being given "heads" as the target so that it will in fact match when all heads
are given.  fixes #267

- move resolution of "starting rev" for --sql mode into
get_current_heads() directly; therefore we don't need to
do this in alembic.command, which we were doing for stamp but
not downgrade/upgrade.  The slight change here is that the
context.get_starting_revision_argument() method will
return an abbreviated starting rev as abbreviated in
all cases, including the stamp command, where we previously
were converting a stamp argument first, but not for the
upgrade or downgrade commands.
- Fixed bug where using a partial revision identifier as the
"starting revision" in ``--sql`` mode in a downgrade operation
would fail to resolve properly.  fixes #269

remove errant pdb

- Added a new feature :attr:`.Config.attributes`, to help with the use
case of sharing state such as engines and connections on the outside
with a series of Alembic API calls; also added a new cookbook section
to describe this simple but pretty important use case.

fix missing changelog directive

- Added support for "alembic stamp" to work when given "heads" as an
argument, when multiple heads are present.
fixes #267

- set up for next rev

- fix all flake8

- the enum render is an 0.9 regression, apparently we used
a different repr() scheme in 0.7.9->0.8 that didn't omit native_enum

- 0.7.4

- happy new year

changelog for #241, fixes #241

Merge https://bitbucket.org/dtheodor/alembic/branch/master into pr37

checked test failure

remove redundant Float type check

Enum autogenerate renders the native_enum flag as well

Change single-quoting of floats in PostgreSQL compare_server_default

Do not wrap string defaults with single quotes when comparing against
columns of type float or numeric.
This fixes the crash occuring when the default of a float column is
an integer value (e.g., DEFAULT 5), while the Python server_default is
a string (e.g., server_default="5.0"). This results in the query
used in the comparison to throw a DataError ('SELECT 5 = '5.0').

- The rendering of a :class:`~sqlalchemy.schema.ForeignKeyConstraint`
will now ensure that the names of the source and target columns are
the database-side name of each column, and not the value of the
``.key`` attribute as may be set only on the Python side.
This is because Alembic generates the DDL for constraints
as standalone objects without the need to actually refer to an in-Python
:class:`~sqlalchemy.schema.Table` object, so there's no step that
would resolve these Python-only key names to database column names.
fixes #259

- Fixed bug in foreign key autogenerate where if the in-Python table
used custom column keys (e.g. using the ``key='foo'`` kwarg to
``Column``), the comparison of existing foreign keys to those specified
in the metadata would fail, as the reflected table would not have
these keys available which to match up.  Foreign key comparison for
autogenerate now ensures it's looking at the database-side names
of the columns in all cases; this matches the same functionality
within unique constraints and indexes.
fixes #260

- make this test use legal table designs

- add/remove seemed backwards here

- changelog:  Fixed issue in autogenerate type rendering where types that belong
to modules that have the name "sqlalchemy" in them would be mistaken
as being part of the ``sqlalchemy.`` namespace.  Pull req courtesy
Bartosz Burclaf.  fixes #261

Fixes user module namespace for custom types

0.7.3

- Fixed regression in new versioning system where upgrade / history
operation would fail on AttributeError if no version files were
present at all.
fixes #258

- put sqlalchemy master here as SQLA issue https://bitbucket.org/zzzeek/sqlalchemy/issue/3218
is blowing up our sphinx build

0.7.2

- Adjusted the SQLite backend regarding autogen of unique constraints
to work fully with the current SQLAlchemy 1.0, which now will report
on UNIQUE constraints that have no name.
- fix named foreign key test requirements for SQLAlchemy 1.0 sqlite
FK reflection

- identify a test that can't pass on 0.8 for now

- also add an explicit schema test for the multi fk condition

- Fixed bug in batch where if the target table contained multiple
foreign keys to the same target table, the batch mechanics would
fail with a "table already exists" error.  Thanks for the help
on this from Lucas Kahlert. fixes #254

-Repaired a regression in both the MSSQL and Oracle dialects whereby
the overridden ``_exec()`` method failed to return a value, as is
needed now in the 0.7 series. fixes #253
- add __backend__ to UpdateRevTest which does a great job testing
_exec() pathing for all backends

- adjust test here so that it applies to all backends
- skip index at the level of the index, not the columns inside it
- changelog
- bump for 0.7.2

Merge branch 'mysql-unique-index-removed' of https://bitbucket.org/jerdfelt/alembic into pr35

MySQL: Ignore unique indexes when removing implicit indexes

MySQL will implicitly create indexes when using foreign keys. Alembic
attempts to remove those implicit indexes so they don't appear as
removes when comparing metadata.

However, unique indexes with the same name as a column are considered
as possibly implicitly created causing alembic to emit a spurious
'remove_constraint'.

Since MySQL will never implicitly create unique indexes, they can be
safely ignored when removing the implicit indexes.

Fixes #251

0.7.1

- The ``render_as_batch`` flag was inadvertently hardcoded to ``True``,
so all autogenerates were spitting out batch mode...this has been
fixed so that batch mode again is only when selected in env.py.

- use a much bigger stamp here as only three chars can collide quite easily

0.7.1

- repair the rendering of add_fk_constraint(), quoting there too

- naming convention limited to SQLA 0.9.4 or greater

- fix drop_foreign_key to include that this only works with SQLite
as stated

- reword the first paragraph about offline mode to better flow
from the preceding sections.

- Added :paramref:`~.Operations.batch_alter_table.naming_convention`
argument to :meth:`.Operations.batch_alter_table`, as this is necessary
in order to drop foreign key constraints; these are often unnamed
on the target database, and in the case that they are named, SQLAlchemy
is as of the 0.9 series not including these names yet.
- rework the docs on batch + constraints, which remains subject
to a lot of caveats and problems, some to be resolved in SQLAlchemy 1.0

- name the include_object hook "foreign_key_constraint"
- changelog and other doc updates, fixes #178
- fix drop_constraint() unit tests and add two more for FKs

- refactor the FK merge a bit
- getting at attributes of FKs varies a bit on SQLA versions,
so implement an _fk_spec() called for all FK inspection
- to enable include_object() filters and allow the FK constraint
code to flow like that of indexes/uniques, change the approach
so that we deal with an _fk_constraint_sig() object again which
contains the real ForeignKeyConstraint() within; we need this
anyway for include_object, but also allows us to use the standard
"drop_constraint" call for rendering.
- enhance tests in test_autogen_fks to support real FK databases like
Postgresql, MySQL, add in InnoDB flags and ensure that FKs refer
to real primary key constraints for PG support
- implement and test include_object() support for FKs
- inspectors all have get_foreign_keys(), no need to check
- repair the drop_constraint call to quote the "type" and table
name correctly, run all constraint drops through drop_constraint()
for rendering
- fix up schema identifiers for foreign key autogens

- Merge branch 'add_fk_check' of https://bitbucket.org/akamyshnikova/alembic into pr32
- complete merge, get all tests passing
- use 'foreignkey' literal

Conflicts:
alembic/autogenerate/compare.py
tests/test_autogenerate.py

- Fixed bug where the "source_schema" argument was not correctly passed
when calling :meth:`.BatchOperations.create_foreign_key`.  Pull
request courtesy Malte Marquarding.
- add tests

Merge branch 'master' of https://bitbucket.org/mmarquar/alembic

- Repaired the inspection, copying and rendering of CHECK constraints
and so-called "schema" types such as Boolean, Enum within the batch
copy system; the CHECK constraint will not be "doubled" when the table is
copied, and additionally the inspection of the CHECK constraint for
its member columns will no longer fail with an attribute error.
fixes #249
- Added two new arguments
:paramref:`.Operations.batch_alter_table.reflect_args`
and :paramref:`.Operations.batch_alter_table.reflect_kwargs`, so that
arguments may be passed directly to suit the
:class:`~.sqlalchemy.schema.Table`
object that will be reflected.

Fix source_schema argument in BatchOperation.create_foreign_key

fix symbol

Fix failing unittests and update compare_fk method

0.7.0

fix manifest

- test runner updates

- add a missing @classmethod decorator...

- The ``alembic revision`` command accepts the ``--sql`` option to
suit some very obscure use case where the ``revision_environment``
flag is set up, so that ``env.py`` is run when ``alembic revision``
is run even though autogenerate isn't specified.   As this flag is
otherwise confusing, error messages are now raised if
``alembic revision`` is invoked with both ``--sql`` and
``--autogenerate`` or with ``--sql`` without
``revision_environment`` being set.
fixes #248

- Relative revision identifiers as used with ``alembic upgrade``,
``alembic downgrade`` and ``alembic history`` can be combined with
specific revisions as well, e.g. ``alembic upgrade ae10+3``, to produce
a migration target relative to the given exact version.

- ensure we include for dependencies when we do a stamp, add an option
to filter_for_lineage

- use the correct method here; this needs to have some tests

yikes forgot batch mode

- spiff up autogenerate docs a bit