This commit is part of a series to retire the Packaging Deb
project. Step 2 is to remove all content from the project
repos, replacing it with a README notification where to find
ongoing work, and how to recover the repo if needed at some
future point (as in
https://docs.openstack.org/infra/manual/drivers.html#retiring-a-project).
Change-Id: I17ea6db0c1cd6373a2978adc466e5533d5b35aaa
* add callback tests with stamp present
* fix bug in stamp MigrationInfo construction
* adjust MigrationInfo API to reflect existence of stamps with multiple
up revisions
Change-Id: I308d1de7854542d4d12bcc743bb5ed7e8e2fbefc
Pull-request: https://bitbucket.org/zzzeek/alembic/pull-requests/68
Fixed bug where autogen comparison of a :class:`.Variant` datatype
would not compare to the dialect level type for the "default"
implementation of the :class:`.Variant`, returning the type as changed
between database and table metadata.
Change-Id: Ie94779ece9f1c768375cdbdc4124c98f9c11bb86
Fixes: #433
prior to version 1.0.10 where a particular bug involving Postgresql
exclude constraints was fixed.
Change-Id: Ief64b19b75e4c2c3661ac95d5b03d0c8e0fe5619
Fixes: #431
Repaired :meth:`.Operations.rename_table` for SQL Server when the
target table is in a remote schema, the schema name is omitted from
the "new name" argument.
Also added some extra tests for sp_rename w/ quoting / case sensitive
names.
Change-Id: I411b32d0c5bba5a466c0b5d6a412c1b7541fdc95
Fixes: #429
Using dateutil.tz to link string names to tzinfo objects,
the create_date can now generate using a named timezone
rather than datetime.now().
Change-Id: I9f151cb9e11da3d68be63d7141f60e7eccb9812c
Fixes: #425
The autogenerate compare scheme now takes into account the name truncation
rules applied by SQLAlchemy's DDL compiler to the names of the
:class:`.Index` object, when these names are dynamically truncated
due to a too-long identifier name. As the identifier truncation is
deterministic, applying the same rule to the metadata name allows
correct comparison to the database-derived name.
Change-Id: I270fbde4430a41f4bcc7857f1932347d86f07675
Fixes: #421
A warning is emitted when an object that's not a
:class:`~sqlalchemy.engine.Connection` is passed to
:meth:`.EnvironmentContext.configure`. For the case of a
:class:`~sqlalchemy.engine.Engine` passed, the check for "in transaction"
introduced in version 0.9.0 has been relaxed to work in the case of an
attribute error, as some users appear to be passing an
:class:`~sqlalchemy.engine.Engine` and not a
:class:`~sqlalchemy.engine.Connection`.
Change-Id: I95ef38955c00511d3055362a03284fb91677595f
Fixes: #419
An adjustment to the bug fix for 🎫`369` to accommodate for
env.py scripts that use an enclosing transaction distinct from the
one that the context provides, so that the check for "didn't commit
the transaction" doesn't trigger in this scenario.
Change-Id: I3c1fa614495b61532999a84b2af3773e4d33c30b
Fixes: #417
The :paramref:`.EnvironmentContext.configure.target_metadata` parameter
may now be optionally specified as a sequence of :class:`.MetaData`
objects instead of a single :class:`.MetaData` object. The
autogenerate process will process the sequence of :class:`.MetaData`
objects in order.
Change-Id: I6485c05d68219ff7af1611b34550487d316e0242
Fixes: #38
A :class:`.CommandError` is now raised when a migration file opens
a database transaction and does not close/commit/rollback, when
the backend database or environment options also specify transactional_ddl
is False. When transactional_ddl is not in use, Alembic doesn't
close any transaction so a transaction opened by a migration file
will cause the following migrations to fail to apply.
Change-Id: I7a9baf18837deb193d9ddc6813955909484d4945
Fixes: #369
Fixed bug where Postgresql JSON/JSONB types rendered on SQLAlchemy
1.1 would render the "astext_type" argument which defaults to
the ``Text()`` type without the module prefix, similarly to the
issue with ARRAY fixed in 🎫`85`.
Also modifies the ARRAY approach from 🎫`85` to be
regular expression based for safer targeting of the inner
repr() type.
Change-Id: I66d51301f4bf5b747b5e8da26a83cbff075d71b2
Fixes: #411
Add full support for Postgresql add_exclude_constraint().
This opens up more of the operations API and serves as a
model for other dialect-specific constraints.
Additionally, gracefully degrade if a given constraint
class is not supported with a warning.
Fixes: #412
Change-Id: I0fb89c840518aaeae97929919356f944479bc756
The ``autoincrement=True`` flag is now rendered within the
:meth:`.Operations.alter_column` operation if the source column indicates
that this flag should be set to True. The behavior is sensitive to
the SQLAlchemy version in place, as the "auto" default option is new
in SQLAlchemy 1.1. When the source column indicates autoincrement
as True or "auto", the flag will render as True if the original column
contextually indicates that it should have "autoincrement" keywords,
and when the source column explcitly sets it to False, this is also
rendered. The behavior is intended to preserve the AUTO_INCREMENT flag
on MySQL as the column is fully recreated on this backend. Note that this
flag does **not** support alteration of a column's "autoincrement" status,
as this is not portable across backends.
Change-Id: I746c4841752adf9342bfdca7c9255aae5110b2ef
Fixes: #413
This allows programmatic use of command.revision() to
specify an ad-hoc process_revision_directives callable,
rather than having it placed via the env.py script.
Co-authored-by: Tyson Holub
Change-Id: Ief1c11fd2a6f10e712851145d6d190a3b167817c
Pull-request: https://github.com/zzzeek/alembic/pull/35
Adds a new codepath into render._repr_type() that will consult
the dialect impl for specific types. On the postgresql side,
the exisiting repr() is combined with a replace featuring
the full autogen render of the nested type.
Co-authored-by: Mike Bayer <mike_mp@zzzcomputing.com>
Fixes: #85
Change-Id: I8796bfeea27d48e6f8bb5ea4562bdc04961ba0d5
Pull-request: https://github.com/zzzeek/alembic/pull/38
Fixed bug in :func:`.ops.create_foreign_key` where the internal table
representation would not be created properly if the foriegn key referred
to a table in a different schema of the same name. Pull request
courtesy Konstantin Lebedev.
Change-Id: I494c95d02aedbfec3b6318d069322b544cf018fb
Pull-request: https://github.com/zzzeek/alembic/pull/36
Uses new [tool:pytest] directive.
Also removes tox minversion as we are well ahead of that version.
Change-Id: I32c767b8daa64c9e8d71a68c4f568d275719c7d7
The alembic_version table, when initially created, now establishes a
primary key constraint on the "version_num" column, to suit database
engines that don't support tables without primary keys. This behavior
can be controlled using the parameter
:paramref:`.EnvironmentContext.configure.version_table_pk`. Note that
this change only applies to the initial creation of the alembic_version
table; it does not impact any existing alembic_version table already
present.
Change-Id: Ic947f0f97373b2e6695e06c9b2ad6c8a9789fcb2
Fixes: #406
- Current mysqlclient does not accept "bytes" on py3k, SQLAlchemy 0.9
still lists this client (the original mysqldb version) as
"supports_unicode_statements=False" so is no longer functional on py3k.
- Rollback transaction after table drop; it seems py3.6 sqlite3
suddenly turned on transactional DDL for SQLite
Change-Id: Ic3b7881583bde5602e54811cf6a149761038b9fd
Adjusted the logic originally added for 🎫`276` that detects MySQL
unique constraints which are actually unique indexes to be generalized
for any dialect that has this behavior, for SQLAlchemy version 1.0 and
greater. This is to allow for upcoming SQLAlchemy support for unique
constraint reflection for Oracle, which also has no dedicated concept of
"unique constraint" and instead establishes a unique index.
Change-Id: Ie5770aba36005ec8618bdc18bc4633413d37fc16
Start getting all the exclusions and conventions in place
to get the autogen suites to pass against the oracle dialect
Change-Id: I63b8c46311af4fc77da6baf17b628a64e9748f85
Tony Breeds