| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To accommodate SQLAlchemy 1.4 and 2.0, the migration model now no longer
assumes that the SQLAlchemy Connection will autocommit an individual
operation. This essentially means that for databases that use
non-transactional DDL (pysqlite current driver behavior, MySQL), there is
still a BEGIN/COMMIT block that will surround each individual migration.
Databases that support transactional DDL should continue to have the
same flow, either per migration or per-entire run, depending on the
value of the :paramref:`.Environment.configure.transaction_per_migration`
flag.
Compatibility is established such that the entire library should
not generate any SQLAlchemy 2.0 deprecation warnings and
SQLALCHEMY_WARN_20 is part of conftest.py. (one warning remains
for the moment that needs to be resolved on the SQLAlchemy side)
The test suite requires SQLAlchemy 1.4.0b2 for testing 1.4;
1.4.0b1 won't work.
Test suite / setup also being modernized, as we are at
SQLAlchemy 1.3 we can now remove the majority of the testing
suite plugin.
Change-Id: If55b1ea3c12ead66405ab3fadc76d15d89dabb90
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Made an adjustment to the PostgreSQL dialect to allow it to work more
effectively in batch mode, where a datatype like Boolean or non-native Enum
that may have embedded rules to generate CHECK constraints will be more
correctly handled in that these constraints usually will not have been
generated on the PostgreSQL backend; previously it would inadvertently
assume they existed unconditionally in a special PG-only "drop constraint"
step.
Change-Id: I024b07bee6eec92061d902cbe1b086cb5b3ecd7c
Fixes: #773
|
|
|
|
|
|
|
|
| |
Added missing "create comment" feature for columns that are altered in
batch migrations.
Change-Id: I7468937702cefc8f581e27b1c4ba670e4f8b7d17
Fixes: #761
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Modified the ``add_column()`` operation such that the ``Column`` object in
use is shallow copied to a new instance if that ``Column`` is already
attached to a ``table()`` or ``Table``. This accommodates for the change
made in SQLAlchemy issue #5618 which prohibits a ``Column`` from being
associated with multiple ``table()`` objects. This resumes support for
using a ``Column`` inside of an Alembic operation that already refers to a
parent ``table()`` or ``Table`` as well as allows operation objects just
autogenerated to work.
Change-Id: Idc6933cf0da40373f4f270d75883995822c072f0
Fixes: #753
|
|
|
|
|
|
|
| |
* ``--head_only`` option to the ``alembic current`` command
* legacy argument names in operations, deprecated since version 0.8
Change-Id: Ib6e265e3c2820971d446a1568de16e4a6efb18eb
|
|
|
|
|
| |
Fixes: #748
Change-Id: I18df97bdce5de6adb222d3f16486272e95b1b1a6
|
|
|
|
|
|
|
| |
Existence of a column check used ``ColumnCollection.contains_column`` with a
the name of the column instead of the column instance.
Change-Id: I41d9f6b6ed9e44eeb9ced78b039da6261491eeee
|
|
|
|
|
|
|
|
|
| |
Added support to drop named CHECK constraints that are specified as part of
a column, rather than table wide. Previously, only constraints associated
with the table were considered.
Change-Id: Id1765357e0fa59745b41ba233b18a53e38358e0b
Fixes: #711
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixed issue where the CAST applied to a JSON column when copying a SQLite
table during batch mode would cause the data to be lost, as SQLite's CAST
with JSON appears to convert the data to the value "0". The CAST is now
skipped in a dialect-specific manner, including for JSON columns on SQLite.
Pull request courtesy Sebastián Ramírez.
Fixes: #697
Closes: #698
Pull-request: https://github.com/sqlalchemy/alembic/pull/698
Pull-request-sha: 6618325258bd90ec257b09c17d44421a5642b1b1
Change-Id: Ia152ea7386e64efb2194aa836dc57754f979e204
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The ``alembic current`` command no longer creates an ``alembic_version``
table in the database if one does not exist already, returning no version
as the current version. This allows checking for migrations in parallel
without introducing race conditions. Pull request courtesy Nikolay
Edigaryev.
Fixes: #694
Closes: #695
Pull-request: https://github.com/sqlalchemy/alembic/pull/695
Pull-request-sha: fd3e3b8faf7a41dd4c35daca6c7d224e983ab496
Change-Id: I500ab9ec1fe74b5e20e6aecfe598bce7e9cdef96
|
|
|
| |
Fixes the wrong version in `table_kwargs`. See: https://alembic.sqlalchemy.org/en/latest/ops.html#alembic.operations.Operations.batch_alter_table
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
SQLAlchemy in 1.3 / master is now checking that re-thrown exceptions
have a cause, which we haven't implemented for Alembic yet.
If we did implement this for Alembic, we'd still need to
vendor these two anyway to test. See
https://github.com/sqlalchemy/sqlalchemy/issues/4849
Also add "table_or_column_check_constraint" target so that
builds can pass, this was added for 1.4 / master
in
https://github.com/sqlalchemy/sqlalchemy/commit/ca2e4f385802799c2584782a8528e19a9e5513bc
Change-Id: I07fb2a380f027c44f6bb36e9499da2e8ae2223e7
|
|
|
|
|
|
|
|
|
|
| |
Fixed long-standing bug where an inline column CHECK constraint would not
be rendered within an "ADD COLUMN" operation. The DDL compiler is now
consulted for inline constraints within the :meth:`.Operations.add_column`
method as is done for regular CREATE TABLE operations.
Change-Id: Ib176d13dd9151e65a1ca27357f7da0d4523f0b2f
Fixes: #655
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Added new parameters :paramref:`.BatchOperations.add_column.insert_before`,
:paramref:`.BatchOperations.add_column.insert_after` which provide for
establishing the specific position in which a new column should be placed.
Also added :paramref:`.Operations.batch_alter_table.partial_reordering`
which allows the complete set of columns to be reordered when the new table
is created. Both operations apply only to when batch mode is recreating
the whole table using ``recreate="always"``. Thanks to Marcin Szymanski
for assistance with the implementation.
Co-Authored-by: Mike Bayer <mike_mp@zzzcomputing.com>
Fixes: #640
Closes: #646
Pull-request: https://github.com/sqlalchemy/alembic/pull/646
Pull-request-sha: 29392b796dd995fabdabe50e8725385dbe1b4883
Change-Id: Iec9942baa08da4a7fc49b69093e84785fea3cec2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Modified the logic of the :class:`.Rewriter` object such that it keeps a
memoization of which directives it has processed, so that it can ensure it
processes a particular directive only once, and additionally fixed
:class:`.Rewriter` so that it functions correctly for multiple-pass
autogenerate schemes, such as the one illustrated in the "multidb"
template. By tracking which directives have been processed, a
multiple-pass scheme which calls upon the :class:`.Rewriter` multiple times
for the same structure as elements are added can work without running
duplicate operations on the same elements more than once.
Change-Id: I2cef13d51912f9d86ddd99b60e4d5b96dbf680ff
Fixes: #505
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- SQLite server default reflection will ensure parenthesis are surrounding a
column default expression that is detected as being a non-constant
expression, such as a ``datetime()`` default, to accommodate for the
requirement that SQL expressions have to be parenthesized when being sent
as DDL. Parenthesis are not added to constant expressions to allow for
maximum cross-compatibility with other dialects and existing test suites
(such as Alembic's), which necessarily entails scanning the expression to
eliminate for constant numeric and string values. The logic is added to the
two "reflection->DDL round trip" paths which are currently autogenerate and
batch migration. Within autogenerate, the logic is on the rendering side,
whereas in batch the logic is installed as a column reflection hook.
- Improved SQLite server default comparison to accommodate for a ``text()``
construct that added parenthesis directly vs. a construct that relied
upon the SQLAlchemy SQLite dialect to render the parenthesis, as well
as improved support for various forms of constant expressions such as
values that are quoted vs. non-quoted.
- Fixed bug where the "literal_binds" flag was not being set when
autogenerate would create a server default value, meaning server default
comparisons would fail for functions that contained literal values.
Fixes: #579
Change-Id: I78b87573b8ecd15cb4ced08f054902f574e3956c
|
|
|
|
|
|
| |
of flake8-rst-docstrings
Change-Id: I19288e69128648045d826045343fa5c1c8426ec2
|
|
|
|
|
|
|
|
|
|
|
| |
Corrected the links and text in the changelog note as well as
ensured new comment-oriented methods and parameters include a
versionadded token. Added a more specific check so that
any run of the tests will make sure SQLAlchemy issue 4436
is resolved as 1.2.16 resolves it but 1.3.0b1, which currently
comes out for "python setup.py test", does not.
Change-Id: Ibd94bf7940b279e85b0ec1ddceb309df0c18f0b1
|
|
|
|
|
|
|
|
|
|
| |
Added Table and Column level comments for supported backends.
`create_table`, `add_column` and `alter_column` now optionally
take `comment="X"` kwarg. Support for autogenerate for Table
and Column objects has also been added
Fixes: #422
Change-Id: I1fd37bb7fe3d167baf7b1e7bf7ff5bfd48e7cf54
|
|
|
|
|
|
|
|
| |
An import cycle created by importing an object from
__init__.py is resolved by importing from the local
module.
Change-Id: Idbd357dcfbb792cafe3c765f7bb8b1d19aa16971
|
|
|
|
|
|
|
| |
after black is applied, rewrite imports and fix
remaining whitespace / identifier issues.
Change-Id: I49474c085b5f4a4b52e4cf90c9705d6a896d4003
|
|
|
|
|
|
|
| |
run black -l 79 against source code, set up for
full flake8 testing.
Change-Id: I4108e1274d49894b9898ec5bd3a1147933a473d7
|
|
|
|
|
|
|
|
|
| |
Apparently op.execute() makes use of _exec() which coerces strings
into text() constructs. This is less than ideal, however for now
document the caveat that colons need to be escaped.
Change-Id: I17e0ff6a46e6f5be93e692a67ddd8e7b523d9508
Fixes: #522
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Resolved remaining Python 3 deprecation warnings, covering
the use of inspect.formatargspec() with a vendored version
copied from the Python standard library, importing
collections.abc above Python 3.3 when testing against abstract
base classes, fixed one occurrence of log.warn(), as well as a few
invalid escape sequences.
Add DeprecationWarning to the test suite as an error raise
as has been the case within SQLAlchemy for some time now.
Fixes: #507
Co-authored-by: Mike Bayer <mike_mp@zzzcomputing.com>
Change-Id: I121121b3d2dd90e6f3c9b16dec2fc80b9699c400
Pull-request: https://bitbucket.org/zzzeek/alembic/pull-requests/85
|
|
|
|
|
|
|
| |
With the 1.0 release, Alembic's minimum SQLAlchemy support version
moves to 0.9.0, previously 0.7.9.
Change-Id: I299d8af11c5982c4a792da1fcb96e4b437af687d
|
|
|
|
|
|
|
|
|
|
| |
Fixed issue in batch where dropping a primary key column, then adding it
back under the same name but without the primary_key flag, would not remove
it from the existing PrimaryKeyConstraint. If a new PrimaryKeyConstraint
is added, it is used as-is, as was the case before.
Change-Id: Id79c793fbde1a17393adeb75c2da39f191e676e6
Fixes: #502
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixed a few Python3.6 deprecation warnings by replacing ``StopIteration``
with ``return``, as well as using ``getfullargspec()`` instead of
``getargspec()`` under Python 3.
Additionally fixed docstrings with backslashes needing r'', filehandles
not explicitly closed, accommodate for .pyc files not necessarily present.
Change-Id: Id9791c5fa8b4b1f3e4e36f237a8a8ebcef4aaaba
Fixes: #458
|
|
|
|
|
|
|
|
|
|
| |
The name of the temporary table in batch mode is now generated
off of the original table name itself, to avoid conflicts for the
unusual case of multiple batch operations running against the same
database schema at the same time.
Change-Id: Idbeabf9558887d3f5525e7045d5de33bab6805a5
Fixes: #457
|
|
|
|
|
| |
Change-Id: I89c98401d3e1f1252041b622e045c6dc85fa59a1
Fixes: #424
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
Refer to Operations.alter_column instead of Operations.add_column
|
|
|
|
|
|
| |
fixes #408
Change-Id: Ia569191d43d49178f78a7bcef458b671f750583e
|
|
|
|
|
|
|
|
|
| |
Fixed bug where doing ``batch_op.drop_constraint()`` against the
primary key constraint would fail to remove the "primary_key" flag
from the column, resulting in the constraint being recreated.
Change-Id: I20c04860b151ac86466337f0522018be06c6feec
Fixes: #402
|
|
|
|
|
|
|
|
|
|
|
| |
Batch mode will not use CAST() to copy data if type_ is given, however
the basic type affinity matches that of the existing type. This to
avoid SQLite's CAST of TIMESTAMP which results in truncation of the
data, in those cases where the user needs to add redundant type_ for
other reasons.
Change-Id: I20f7b399cd3cd7740d67ff7d624aa1da874ebc71
Fixes: #391
|
|
|
|
|
|
|
|
|
|
|
| |
Added support for the USING clause to the ALTER COLUMN operation
for Postgresql. Support is via the
:paramref:`.op.alter_column.postgresql_using`
parameter.
Fixes: #292
Change-Id: I8b1d418df0b6b731a68614dbffd7a9fb13de4de5
Pull-request: https://github.com/zzzeek/alembic/pull/27
|
| |
|
|
|
|
|
|
|
| |
constraints to accommodate for SQLAlchemy 1.1 now reflecting these.
Batch mode still does not support CHECK constraints from the reflected
table as these can't be easily differentiated from the ones created
by types such as Boolean.
|
|\ |
|
| | |
|
|\ \
| |/
|/|
| | |
https://bitbucket.org/koniiiik/alembic into pr53
|
| | |
|
| | |
|
| | |
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
constraints, in particular the ``Boolean`` datatype which generates
a CHECK constraint. Previously, an alter column operation with this
type would fail to correctly accommodate for the CHECK constraint
on change both from and to this type. In the former case the operation
would fail entirely, in the latter, the CHECK constraint would
not get generated. Both of these issues are repaired.
fixes #354
- Changing a schema type such as ``Boolean`` to a non-schema type would
emit a drop constraint operation which emits ``NotImplementedError`` for
the MySQL dialect. This drop constraint operation is now skipped when
the constraint originates from a schema type.
fixes #355
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
using the ultimate table name, rather than ``_alembic_batch_temp``.
When the table is renamed from ``_alembic_batch_temp`` back to the
original name, the FK now points to the right name. This
will **not** work if referential integrity is being enforced (eg. SQLite
"PRAGMA FOREIGN_KEYS=ON") since the original table is dropped and
the new table then renamed to that name, however this is now consistent
with how foreign key constraints on **other** tables already operate
with batch mode; these don't support batch mode if referential integrity
is enabled in any case.
fixes #345
|
|
|
|
|
|
| |
schema type constraint; existing_type is. I haven't checked to
see if this changed at some point but that's what the source code
right now says.
|
|
|
|
|
| |
would not function correctly in batch mode.
fixes #338
|
|
|
|
|
|
|
|
|
|
|
| |
would create the same index on the new table with the same name,
which on SQLite produces a naming conflict as index names are in a
global namespace on that backend. Batch mode now defers the production
of both existing and new indexes until after the entire table transfer
operation is complete, which also means those indexes no longer take
effect during the INSERT from SELECT section as well; the indexes
are applied in a single step afterwards.
fixes #333
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
failed to produce independent migration script segments for the
output template. This was due to the reorganization of the script
rendering system for 0.8. To accommodate this change, the
:class:`.MigrationScript` structure will in the case of multiple
calls to :meth:`.MigrationContext.run_migrations` produce lists
for the :attr:`.MigrationScript.upgrade_ops` and
:attr:`.MigrationScript.downgrade_ops` attributes; each :class:`.UpgradeOps`
and :class:`.DowngradeOps` instance keeps track of its own
``upgrade_token`` and ``downgrade_token``, and each are rendered
individually.
fixes #318
|