Mike Bayer [Wed, 27 Aug 2014 23:22:42 +0000 (19:22 -0400)]
- Added support for functional indexes when using the
:meth:`.Operations.create_index` directive. Within the list of columns,
the SQLAlchemy ``text()`` construct can be sent, embedding a literal
SQL expression; the :meth:`.Operations.create_index` will perform some hackery
behind the scenes to get the :class:`.Index` construct to cooperate.
This works around some current limitations in :class:`.Index`
which should be resolved on the SQLAlchemy side at some point.
fixes #222
Mike Bayer [Mon, 23 Jun 2014 17:49:44 +0000 (13:49 -0400)]
- Some deep-in-the-weeds fixes to try to get "server default" comparison
working better across platforms and expressions, in particular on
the Postgresql backend, mostly dealing with quoting/not quoting of various
expressions at the appropriate time and on a per-backend basis.
Repaired and tested support for such defaults as Postgresql interval
and array defaults.
fixes #212
Mike Bayer [Thu, 12 Jun 2014 14:30:14 +0000 (10:30 -0400)]
- When a run of Alembic command line fails due to ``CommandError``,
the output now prefixes the string with ``"FAILED:"``, and the error
is also written to the log output using ``log.error()``.
fixes #209
Mike Bayer [Thu, 5 Jun 2014 20:22:14 +0000 (16:22 -0400)]
- Liberalized even more the check for MySQL indexes that shouldn't be
counted in autogenerate as "drops"; this time it's been reported
that an implicitly created index might be named the same as a composite
foreign key constraint, and not the actual columns, so we now skip those
when detected as well. fixes #208
Marc Abramowitz [Wed, 28 May 2014 15:54:28 +0000 (08:54 -0700)]
Eliminate {} (dict) default arg value for `opts`
to MigrationContext.configure
Using a mutable type as a default value is a common source of obscure
problems.
See
http://docs.python-guide.org/en/latest/writing/gotchas/#mutable-default-arguments
Mike Bayer [Fri, 2 May 2014 20:04:43 +0000 (16:04 -0400)]
- This releases' "autogenerate index detection" bug, when a MySQL table
includes an Index with the same name as a column, autogenerate reported
it as an "add" even though its not; this is because we ignore reflected
indexes of this nature due to MySQL creating them implicitly. Indexes
that are named the same as a column are now ignored on
MySQL if we see that the backend is reporting that it already exists;
this indicates that we can still detect additions of these indexes
but not drops, as we cannot distinguish a backend index same-named
as the column as one that is user generated or mysql-generated.
fixes #202
Mike Bayer [Fri, 2 May 2014 19:46:00 +0000 (15:46 -0400)]
- Added new feature :paramref:`.EnvironmentContext.configure.transaction_per_migration`,
which when True causes the BEGIN/COMMIT pair to incur for each migration
individually, rather than for the whole series of migrations. This is
to assist with some database directives that need to be within individual
transactions, without the need to disable transactional DDL entirely.
fixes #201
Mike Bayer [Wed, 30 Apr 2014 22:28:49 +0000 (18:28 -0400)]
- Fixed bug where the ``include_object()`` filter would not receive
the original :class:`.Column` object when evaluating a database-only
column to be dropped; the object would not include the parent
:class:`.Table` nor other aspects of the column that are important
for generating the "downgrade" case where the column is recreated.
fixes #200
Mike Bayer [Fri, 4 Apr 2014 15:09:34 +0000 (11:09 -0400)]
- Fixed bug where :meth:`.EnvironmentContext.get_x_argument`
would fail if the :class:`.Config` in use didn't actually
originate from a command line call. fixes #195
Mike Bayer [Tue, 1 Apr 2014 17:12:51 +0000 (13:12 -0400)]
Fixed another bug regarding naming conventions, continuing
from :ticket:`183`, where add_index()
drop_index() directives would not correctly render the ``f()``
construct when the index contained a convention-driven name.
fixes #194 re: #183
Mike Bayer [Tue, 25 Mar 2014 23:16:15 +0000 (19:16 -0400)]
- Added quoting to the table name when the special EXEC is run to
drop any existing server defaults or constraints when the
:paramref:`.drop_column.mssql_drop_check` or
:paramref:`.drop_column.mssql_drop_default`
arguments are used. fix #186
Mike Bayer [Sun, 16 Mar 2014 23:26:21 +0000 (19:26 -0400)]
- Added/fixed support for MySQL "SET DEFAULT" / "DROP DEFAULT" phrases,
which will now be rendered if only the server default is changing
or being dropped (e.g. specify None to alter_column() to indicate
"DROP DEFAULT"). Also added support for rendering MODIFY rather than
CHANGE when the column name isn't changing.
fixes #103
Mike Bayer [Fri, 14 Mar 2014 20:41:21 +0000 (16:41 -0400)]
- Added support for the ``initially``, ``match`` keyword arguments
as well as dialect-specific keyword arguments to
:meth:`.Operations.create_foreign_key`.
fixes #190
Mike Bayer [Fri, 14 Mar 2014 14:47:55 +0000 (10:47 -0400)]
- Altered the support for "sourceless" migration files (e.g. only
.pyc or .pyo present) so that the flag "sourceless=true" needs to
be in alembic.ini for this behavior to take effect.
fixes #163
Mike Bayer [Fri, 14 Mar 2014 14:17:37 +0000 (10:17 -0400)]
- ensure that target_metadata is also present in the offline migration context,
so that --sql mode gets access to naming conventions also.
existing environments need to add target_metadata to the offline migration
context manually.
fixes #189
Mike Bayer [Thu, 13 Mar 2014 17:52:11 +0000 (13:52 -0400)]
The feature that keeps on giving, index/unique constraint autogenerate
detection, has even more fixes, this time to accommodate database dialects
that both don't yet report on unique constraints, but the backend
does report unique constraints as indexes. The logic
Alembic uses to distinguish between "this is an index!" vs.
"this is a unique constraint that is also reported as an index!" has now
been further enhanced to not produce unwanted migrations when the dialect
is observed to not yet implement get_unique_constraints() (e.g. mssql).
Note that such a backend will no longer report index drops for unique
indexes, as these cannot be distinguished from an unreported unique
index. fixes #185
Mike Bayer [Wed, 12 Mar 2014 21:34:01 +0000 (17:34 -0400)]
Extensive changes have been made to more fully support SQLAlchemy's new
naming conventions feature. Note that while SQLAlchemy has added this
feature as of 0.9.2, some additional fixes in 0.9.4 are needed to
resolve some of the issues:
1. The :class:`.Operations` object now takes into account the naming
conventions that are present on the :class:`.MetaData` object that's
associated using :paramref:`~.EnvironmentContext.configure.target_metadata`.
When :class:`.Operations` renders a constraint directive like
``ADD CONSTRAINT``, it now will make use of this naming convention
when it produces its own temporary :class:`.MetaData` object.
2. Note however that the autogenerate feature in most cases generates
constraints like foreign keys and unique constraints with the
final names intact; the only exception are the constraints implicit
with a schema-type like Boolean or Enum. In most of these cases,
the naming convention feature will not take effect for these constraints
and will instead use the given name as is, with one exception....
3. Naming conventions which use the ``"%(constraint_name)s"`` token, that
is, produce a new name that uses the original name as a component,
will still be pulled into the naming convention converter and be
converted. The problem arises when autogenerate renders a constraint
with it's already-generated name present in the migration file's source
code, the name will be doubled up at render time due to the combination
of #1 and #2. So to work around this, autogenerate now renders these
already-tokenized names using the new :meth:`.Operations.f` component.
This component is only generated if **SQLAlchemy 0.9.4** or greater
is in use.
Therefore it is highly recommended that an upgrade to Alembic 0.6.4
be accompanied by an upgrade of SQLAlchemy 0.9.4, if the new naming
conventions feature is used.
Mike Bayer [Tue, 11 Mar 2014 00:30:03 +0000 (20:30 -0400)]
- Suppressed IOErrors which can raise when program output pipe
is closed under a program like ``head``; however this only
works on Python 2. On Python 3, there is not yet a known way to
suppress the BrokenPipeError warnings without prematurely terminating
the program via signals. fixes #160.
Added comments to http://bugs.python.org/issue11380 to see what the
status is on py3k.
Mike Bayer [Sat, 8 Mar 2014 05:15:46 +0000 (00:15 -0500)]
- Fixed bug where :meth:`.Operations.bulk_insert` would not function
properly when :meth:`.Operations.inline_literal` values were used,
either in --sql or non-sql mode. The values will now render
directly in --sql mode. For compatibility with "online" mode,
a new flag :paramref:`~.Operations.inline_literal.multiparams`
can be set to False which will cause each parameter set to be
compiled and executed with individual INSERT statements.
fixes #179
Mike Bayer [Wed, 19 Feb 2014 01:44:16 +0000 (20:44 -0500)]
- Fixed a failure of the system that allows "legacy keyword arguments"
to be understood, which arose as of a change in Python 3.4 regarding
decorators. A workaround is applied that allows the code to work
across Python 3 versions. #175
Mike Bayer [Sun, 2 Feb 2014 21:42:29 +0000 (16:42 -0500)]
- Added a workaround for when we call ``fcntl.ioctl()`` to get at
``TERMWIDTH``; if the function returns zero, as is reported to occur
in some pseudo-ttys, the message wrapping system is disabled in the
same way as if ``ioctl()`` failed. #172
Mike Bayer [Sat, 1 Feb 2014 17:29:03 +0000 (12:29 -0500)]
- Added new argument
:paramref:`.EnvironmentContext.configure.user_module_prefix`.
This prefix is applied when autogenerate renders a user-defined type,
which here is defined as any type that is from a module outside of the
``sqlalchemy.`` hierarchy. This prefix defaults to ``None``, in
which case the :paramref:`.EnvironmentContext.configure.sqlalchemy_module_prefix`
is used, thus preserving the current behavior. #171
- added new documentation sections regarding rendering of types
- improved CSS so that deprecations/version changes are highlighted
- cleanup of some configure paramter docs
Mike Bayer [Fri, 31 Jan 2014 01:29:29 +0000 (20:29 -0500)]
- Added support for autogenerate covering the use case where :class:`.Table`
objects specified in the metadata have an explicit ``schema`` attribute
whose name matches that of the connection's default schema
(e.g. "public" for Postgresql). Previously, it was assumed that "schema"
was ``None`` when it matched the "default" schema, now the comparison
adjusts for this. #170
Roman Podoliaka [Tue, 28 Jan 2014 07:08:58 +0000 (09:08 +0200)]
Handle include_* arguments in compare_metadata()
include_object, include_symbol and include_schemas are very useful,
when you need to specify what objects you want to be compared.
Modify compare_metadata() public API function, so that it takes those
arguments into account and pass them to _produce_net_changes().
Mike Bayer [Fri, 24 Jan 2014 15:43:43 +0000 (10:43 -0500)]
- Calling :func:`.bulk_insert` with an empty list will not emit any
commands on the current connection. This was already the case with
``--sql`` mode, so is now the case with "online" mode.
Autogenerate index and unique's comparison takes schema into account
The inspector now will recover the indexes and unique constraints of
the table in the correct schema. Previously it was not taking schema
into account, resulting in always re-creating the existing uniques
and indexes.
Mike Bayer [Sun, 12 Jan 2014 02:55:17 +0000 (21:55 -0500)]
- More fixes to index autodetection; indexes created with expressions
like DESC or functional indexes will no longer cause AttributeError
exceptions when attempting to compare the columns. #164
Mike Bayer [Tue, 31 Dec 2013 20:01:50 +0000 (15:01 -0500)]
- The :class:`.ScriptDirectory` system that loads migration files
from a ``versions/`` directory now supports so-called
"sourceless" operation, where the ``.py`` files are not present
and instead ``.pyc`` or ``.pyo`` files are directly present where
the ``.py`` files should be. Note that while Python 3.3 has a
new system of locating ``.pyc``/``.pyo`` files within a directory
called ``__pycache__`` (e.g. PEP-3147), PEP-3147 maintains
support for the "source-less imports" use case, where the
``.pyc``/``.pyo`` are in present in the "old" location, e.g. next
to the ``.py`` file; this is the usage that's supported even when
running Python3.3. #163
Mike Bayer [Fri, 27 Dec 2013 17:37:07 +0000 (12:37 -0500)]
- clean out test_autogenerate
- start pinning some tests to 0.9, don't need to pin to 0.7 anymore
- Autogenerate for ``op.create_table()`` will not include a
``PrimaryKeyConstraint()`` that has no columns.
- don't need a full string test for boolean/check constraint autogen