summaryrefslogtreecommitdiff
path: root/alembic/operations
Commit message (Collapse)AuthorAgeFilesLines
...
* Accommodate SQLAlchemy 1.4/2.0CaselIT2021-01-112-42/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Consult ApplyBatchImpl for hints on constraints to dropMike Bayer2020-12-281-1/+1
| | | | | | | | | | | | | 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
* Implement column comments for batchMike Bayer2020-11-271-0/+17
| | | | | | | | Added missing "create comment" feature for columns that are altered in batch migrations. Change-Id: I7468937702cefc8f581e27b1c4ba670e4f8b7d17 Fixes: #761
* Copy column that's already attachedMike Bayer2020-11-051-0/+3
| | | | | | | | | | | | | | 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
* Removed of old deprecated code:CaselIT2020-10-271-34/+8
| | | | | | | * ``--head_only`` option to the ``alembic current`` command * legacy argument names in operations, deprecated since version 0.8 Change-Id: Ib6e265e3c2820971d446a1568de16e4a6efb18eb
* Remove support for Python 3.5 and SQLAlchemy older than the 1.3 series.CaselIT2020-10-262-12/+7
| | | | | Fixes: #748 Change-Id: I18df97bdce5de6adb222d3f16486272e95b1b1a6
* Fix column existence check in batch operationCaselIT2020-09-101-1/+1
| | | | | | | Existence of a column check used ``ColumnCollection.contains_column`` with a the name of the column instead of the column instance. Change-Id: I41d9f6b6ed9e44eeb9ced78b039da6261491eeee
* Support DROP of named check constraint from column for batchMike Bayer2020-07-161-1/+16
| | | | | | | | | 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
* Do not CAST(x as JSON) in SQLiteSebastián Ramírez2020-06-011-6/+12
| | | | | | | | | | | | | | | 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
* Ensure "alembic current" won't unnecessarily mutate the databaseNikolay Edigaryev2020-05-151-1/+0
| | | | | | | | | | | | | | | 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
* Fix typo in documentationFederico Caselli2020-04-071-1/+1
| | | Fixes the wrong version in `table_kwargs`. See: https://alembic.sqlalchemy.org/en/latest/ops.html#alembic.operations.Operations.batch_alter_table
* Vendor assert_raises[_message], add new check constraint targetMike Bayer2020-03-051-0/+2
| | | | | | | | | | | | | | | 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
* Render inline constraints for add_columnMike Bayer2020-02-061-0/+1
| | | | | | | | | | 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
* Support explicit column ordering in batch modeMarcin Szymanski2020-02-044-7/+177
| | | | | | | | | | | | | | | | | | | 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
* Memoize elements in rewriter; use correct iterationMike Bayer2019-09-181-0/+2
| | | | | | | | | | | | | | | 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
* Ensure SQLite default expressions are parenthesizedMike Bayer2019-06-251-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | - 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
* Fix rst flake8 issues that have come online w/ latest updateMike Bayer2019-05-292-6/+6
| | | | | | of flake8-rst-docstrings Change-Id: I19288e69128648045d826045343fa5c1c8426ec2
* Update comment documentation, make sure tests always runMike Bayer2019-01-111-9/+35
| | | | | | | | | | | 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
* Implemented support for Table and Column CommentsMike Waites2019-01-103-1/+176
| | | | | | | | | | 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
* Fix package local object importMike Bayer2019-01-072-2/+3
| | | | | | | | An import cycle created by importing an object from __init__.py is resolved by importing from the local module. Change-Id: Idbd357dcfbb792cafe3c765f7bb8b1d19aa16971
* zimports runMike Bayer2019-01-066-39/+54
| | | | | | | after black is applied, rewrite imports and fix remaining whitespace / identifier issues. Change-Id: I49474c085b5f4a4b52e4cf90c9705d6a896d4003
* pure black run + flake8Mike Bayer2019-01-066-407/+653
| | | | | | | run black -l 79 against source code, set up for full flake8 testing. Change-Id: I4108e1274d49894b9898ec5bd3a1147933a473d7
* reword op.execute()Mike Bayer2018-12-281-28/+47
| | | | | | | | | 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
* Vendor python3 formatargspec, import from collections.abcStefan Tjarks2018-11-271-3/+3
| | | | | | | | | | | | | | | | | 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
* Drop support for all SQLAlchemy < 0.9Mike Bayer2018-07-132-8/+2
| | | | | | | With the 1.0 release, Alembic's minimum SQLAlchemy support version moves to 0.9.0, previously 0.7.9. Change-Id: I299d8af11c5982c4a792da1fcb96e4b437af687d
* Remove column from primary key when droppingMike Bayer2018-07-121-1/+6
| | | | | | | | | | 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
* Clean up all Python 3.6 warningsMike Bayer2017-10-112-5/+6
| | | | | | | | | | | | 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
* Append table name to batch temp nameMike Bayer2017-10-111-4/+9
| | | | | | | | | | 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
* Add support for kw to DROP INDEX, test postgresql_concurrentlyMike Bayer2017-08-041-6/+20
| | | | | Change-Id: I89c98401d3e1f1252041b622e045c6dc85fa59a1 Fixes: #424
* Add ExcludeConstraint support for PostgresqlMike Bayer2017-02-221-8/+16
| | | | | | | | | | | | 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
* Ensure schema names also compared in foreign_key_constraint()Konstantin Lebedev2017-02-201-1/+1
| | | | | | | | | | 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
* Fix link in batch alter_column docHemanth Makkapati2017-02-131-1/+1
| | | | Refer to Operations.alter_column instead of Operations.add_column
* - add a note that alter_column->postgresql_using is raw SQL,Mike Bayer2017-01-251-1/+3
| | | | | | fixes #408 Change-Id: Ia569191d43d49178f78a7bcef458b671f750583e
* Ensure primary_key flag unset for PK batch dropMike Bayer2016-12-191-2/+6
| | | | | | | | | 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
* cast() types in batch only if type_affinity is differentMike Bayer2016-11-231-1/+4
| | | | | | | | | | | 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
* Support USING for Postgresql ALTER COLUMN.Frazer McLean2016-08-221-0/+6
| | | | | | | | | | | 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
* - repair typoMike Bayer2016-06-021-1/+1
|
* - Small adjustment made to the batch handling for reflected CHECKMike Bayer2016-06-011-4/+11
| | | | | | | 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.
* Merge branch 'master' of https://bitbucket.org/mdomke/alembic into pr55Mike Bayer2016-03-161-1/+4
|\
| * Allow server_default=None for batch operations.Martin Domke2016-03-161-1/+4
| |
* | Merge branch 'mssql_batch_drop_column_fix' of ↵Mike Bayer2016-03-161-2/+2
|\ \ | |/ |/| | | https://bitbucket.org/koniiiik/alembic into pr53
| * Fixed mssql_* kwargs in batch_op.drop_column().Michal Petrucha2016-01-211-2/+2
| |
* | Fix wrong ReST expressionKim Jin Su2016-03-012-3/+3
| |
* | - use compat is_type_bound() functionMike Bayer2016-01-221-1/+1
| |
* | - Repaired batch migration support for "schema" types which generateMike Bayer2016-01-221-1/+28
|/ | | | | | | | | | | | | | | 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
* - Batch mode generates a FOREIGN KEY constraint that is self-referentialMike Bayer2015-12-151-2/+21
| | | | | | | | | | | | | 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
* - existing_server_default is not used to drop the previousMike Bayer2015-12-101-3/+3
| | | | | | 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.
* - Fixed bug where the ``server_default`` parameter of ``alter_column()``Mike Bayer2015-11-221-1/+1
| | | | | would not function correctly in batch mode. fixes #338
* - Fixed bug in batch mode where a table that had pre-existing indexesMike Bayer2015-10-161-6/+20
| | | | | | | | | | | 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
* - Fixed a regression 0.8 whereby the "multidb" environment templateMike Bayer2015-08-201-1/+98
| | | | | | | | | | | | | | 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