summaryrefslogtreecommitdiff
path: root/tests/test_batch.py
Commit message (Collapse)AuthorAgeFilesLines
* restore drop_index.table_name, drop_constraint.type_ as positionalMike Bayer2023-05-161-0/+13
| | | | | | | | | | | | | These two API changes were identified as having legacy use patterns and should be revisited using a deprecation warning for removal in either 1.12 or 1.13. Add documentation re: Alembic not using semver, fix incorrect calling signature example in batch documentation. Change-Id: I33dc5a8d058bcce77591bb037ae964e626a3387f Fixes: #1243 Fixes: #1245
* keyword only arguments in opsMike Bayer2023-05-111-1/+1
| | | | | | | | | | Argument signatures of Alembic operations now enforce keyword-only arguments as passed as keyword and not positionally, such as :paramref:`.Operations.create_table.schema`, :paramref:`.Operations.add_column.type_`, etc. Change-Id: I91b453c8848dc5d24d63840bfd7ce4d22dd0e693 Fixes: #1130
* Fix issues in autogenerate of function index removalCaselIT2023-04-041-1/+0
| | | | | | | | Fixed error raised by alembic when running autogenerate after removing a function based index. Fixes: #1212 Change-Id: Idc565d661229afda89d44e36786bb0357323e604
* distinguish between string contraint name and definedMike Bayer2023-03-061-0/+26
| | | | | | | | | | | | | | Take _NONE_NAME into account as a valid constraint name and don't skip these constraints or consider them to be unnamed. Thanks to typing this also revealed that previous batch versions were also keying "_NONE_NAME" constraints as though they were named. Fixed regression for 1.10.0 where :class:`.Constraint` objects were suddenly required to have non-None name fields when using batch mode, which was not previously a requirement. Change-Id: If4a7191a00848b19cb124bc6da362f3bc6ce1472 Fixes: #1195
* run pyupgradeMike Bayer2022-11-261-28/+18
| | | | | | | | | | | | | | | | | | command is: find alembic -name "*.py" | xargs pyupgrade --py37-plus --keep-runtime-typing --keep-percent-format I'm having some weird fighting with the tools/write_pyi, where in different runtime contexts it keeps losing "MigrationContext" and also Callable drops the args, but it's not consisistent. For whatever reason, under py311 things *do* work every time. im working w/ clean tox environments so not really sure what the change is. anyway, let's at least fix the quoting up around the types. This is towards getting the "*" in the op signatures for #1130. Change-Id: I9175905d3b4325e03a97d6752356b70be20e9fad
* fail gracefully for batch_alter_table() called in --sql modeMike Bayer2022-07-011-0/+171
| | | | | | | | | | | | | | | Added an error raise for the condition where :meth:`.Operations.batch_alter_table` is used in ``--sql`` mode, where the operation requires table reflection, as is the case when running against SQLite without giving it a fixed ``Table`` object. Previously the operation would fail with an internal error. To get a "move and copy" batch operation as a SQL script without connecting to a database, a ``Table`` object should be passed to the :paramref:`.Operations.batch_alter_table.copy_from` parameter so that reflection may be skipped. Change-Id: I2d040e7e5771eefabba1649d71ed451567c25283 Fixes: #1021
* Make alembic compatible with comments on constraintsCaselIT2022-06-251-0/+2
| | | | | | | Make alembic test compatible with comments on constraint change added in Ia60f578595afdbd6089541c9a00e37997ef78ad3 Change-Id: I9ad803df1d3ccf2a5111266b781061936717b8c8
* implement full copy for indexes in batchMike Bayer2022-05-101-7/+25
| | | | | | | | | | | | | Fixed issue in batch mode where CREATE INDEX would not use a new column name in the case of a column rename. Indexes were previously being moved to the new table without any steps to rewrite columns. We now vendor the copy approach from table.to_metadata so that there's a new index expressed in terms of the new columns. Change-Id: Ied84232037aee0b2bf2094b3d3474013d7b41b34 Fixes: #1034
* resolve for variant before testing for schema typeMike Bayer2022-02-011-0/+24
| | | | | | | | | | | | | | | | | Fixed regression where usage of a ``with_variant()`` datatype in conjunction with the ``existing_type`` option of ``op.alter_column()`` under batch mode would lead to an internal exception. note this exception would only occur under 1.x, under 2.0 the new variant architecture would have prevented this problem, however it is best here that the ultimate variant type is unwrapped in the case that we have a plain type with a schema type as a variant. also sqla 1.3 needs pytest < 7 to run correctly Change-Id: I0f5480f97f014e707b8bd4e70f8495d3bd27fd21 Fixes: #982
* sqlalchemy 2.0 test updatesMike Bayer2021-11-051-25/+31
| | | | | | | | | - disable branched connection tests for 2.x - dont use future flag for 2.x - adjust batch tests for autobegin, inconsistent SQLite transactional DDL behaviors Change-Id: I70caf6afecc83f880dc92fa6cbc29e2043c43bb9
* check all directives in batch block until recreate selectedMike Bayer2021-08-301-6/+39
| | | | | | | | | | | | Fixed regression in batch mode due to :ticket:`883` where the "auto" mode of batch would fail to accommodate any additional migration directives beyond encountering an ``add_column()`` directive, due to a mis-application of the conditional logic that was added as part of this change, leading to "recreate" mode not being used in cases where it is required for SQLite such as for unique constraints. Change-Id: I6315569caff5f3b33d152974ebecc8b18d9cc523 Fixes: #896
* support named CHECK constraints in batchMike Bayer2021-08-241-13/+56
| | | | | | | | | | | | | | | | | | | Named CHECK constraints are now supported by batch mode, and will automatically be part of the recreated table assuming they are named. They also can be explicitly dropped using ``op.drop_constraint()``. For "unnamed" CHECK constraints, these are still skipped as they cannot be distinguished from the CHECK constraints that are generated by the ``Boolean`` and ``Enum`` datatypes. Note that this change may require adjustments to migrations that drop or rename columns which feature an associated named check constraint, such that an additional ``op.drop_constraint()`` directive should be added for that named constraint as there will no longer be an associated column for it; for the ``Boolean`` and ``Enum`` datatypes, an ``existing_type`` keyword may be passed to ``BatchOperations.drop_constraint`` as well. Fixes: #884 Change-Id: I3694430f7c9735bcc3b0765893b333cc8e0d1cd3
* add req for sqlite computed columnsMike Bayer2021-08-101-0/+1
| | | | | | older Python 3.6 has a sqlite that doesn't support this Change-Id: Ie65ef7fabeae2f5142573247548dd50d6d1708dd
* qualify sqlite batch add column for dynamic defaultsMike Bayer2021-08-101-0/+80
| | | | | | | | | | Batch "auto" mode will now select for "recreate" if the ``add_column()`` operation is used on SQLite, and the column itself meets the criteria for SQLite where ADD COLUMN is not allowed, in this case a functional or parenthesized SQL expression or a ``Computed`` (i.e. generated) column. Change-Id: Ie948b4b8ad8dc698b458403831e47bac4ad45b8a Fixes: #883
* implement table comments for batchMike Bayer2021-04-271-0/+30
| | | | | | | | Added missing ``batch_op.create_table_comment()``, ``batch_op.drop_table_comment()`` directives to batch ops. Change-Id: Ia7779619d150a2fe26abb8a8cc89d147a8432f8c Fixes: #799
* Accommodate SQLAlchemy 1.4/2.0CaselIT2021-01-111-100/+131
| | | | | | | | | | | | | | | | | | | | | | | | | | 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-0/+53
| | | | | | | | | | | | | 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
* Merge "Add more missing mariadb directives"mike bayer2020-11-281-1/+1
|\
| * Add more missing mariadb directivesMike Bayer2020-11-271-1/+1
| | | | | | | | | | | | | | | | Continuing from 985422d42f0670c4019cd3d208aa I6e17f65842bda0aaf6e67437d12078318311eb60 , more mariadb idenifiers needed. Change-Id: Ie1d4067064d445253ab1c6ae9e066eef33e13c4c
* | Implement column comments for batchMike Bayer2020-11-271-0/+88
|/ | | | | | | | Added missing "create comment" feature for columns that are altered in batch migrations. Change-Id: I7468937702cefc8f581e27b1c4ba670e4f8b7d17 Fixes: #761
* Remove support for Python 3.5 and SQLAlchemy older than the 1.3 series.CaselIT2020-10-261-3/+0
| | | | | Fixes: #748 Change-Id: I18df97bdce5de6adb222d3f16486272e95b1b1a6
* Fix column existence check in batch operationCaselIT2020-09-101-0/+16
| | | | | | | 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-0/+56
| | | | | | | | | 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
* Add an additional create_constraintMike Bayer2020-06-031-1/+1
| | | | | | missing from Ic823124446607c2f245663350632382bd1ca10ba Change-Id: Ib9962f1440b6295a64997cf0d09c787fc2624279
* Set create_constraint=True for Enum / Boolean testsMike Bayer2020-06-021-2/+2
| | | | | | | | | | | | In SQLAlchemy [1] [2] we are changing the default for Enum / Boolean create_constraint to False. ensure tests that rely upon this setting being True set it explicitly. [1] I0a3fb608ce32143fa757546cc17ba2013e93272a [2] https://github.com/sqlalchemy/sqlalchemy/issues/5367 Change-Id: Ic823124446607c2f245663350632382bd1ca10ba
* Do not CAST(x as JSON) in SQLiteSebastián Ramírez2020-06-011-18/+37
| | | | | | | | | | | | | | | 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
* Support sqlalchemy 1.4 exec_driver_sql, text() for stringsCaselIT2020-03-181-1/+3
| | | | | | | | | | | Adjusted tests so that only connection-explicit execution is used, along with the use of text() for string invocation. Tests that are testing explicitly for deprecation warnings will bypass SQLAlchemy warnings. Added the RemovedIn20 warning as an error raise for these two specific deprecation cases. Co-authored-by: Mike Bayer <mike_mp@zzzcomputing.com> Change-Id: I4f6b83366329aa95204522c9e99129021d1899fc
* Support explicit column ordering in batch modeMarcin Szymanski2020-02-041-2/+157
| | | | | | | | | | | | | | | | | | | 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
* Use inspect(), not Inspector.from_engine()Mike Bayer2020-02-031-16/+15
| | | | | | | | The internal inspection routines no longer use SQLAlchemy's ``Inspector.from_engine()`` method, which is expected to be deprecated in 1.4. The ``inspect()`` function is now used. Change-Id: I81ea16e5d750d8c48d8db1a5098815988ea60f6c
* fix CAST assertions for SQLA 1.4Mike Bayer2019-08-301-5/+11
| | | | | | | SQLAlchemy 1.4 labels CAST expressions as the name of the column, adjust for this. Change-Id: I208427e9301de224bc108bd97bde4c203faf8196
* Bump to Alembic 1.1, bump requirementsMike Bayer2019-07-211-1/+0
| | | | | | | | Alembic 1.1 bumps the minimum version of SQLAlchemy to 1.1. As was the case before, Python requirements remain at Python 2.7, or in the 3.x series Python 3.4. Change-Id: I68074fb4b59c96c4a596396a69aa143c65d048b5
* Ensure SQLite default expressions are parenthesizedMike Bayer2019-06-251-0/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | - 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
* Tune "rename boolean column w CHECK constraint" test for MySQL 8, mariadb10.2Mike Bayer2019-05-021-1/+1
| | | | | Change-Id: Idb5292f3976b9632069145ff0a7df948a945d7d8 Fixes: #556
* Implemented support for Table and Column CommentsMike Waites2019-01-101-3/+3
| | | | | | | | | | 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
* zimports runMike Bayer2019-01-061-27/+29
| | | | | | | after black is applied, rewrite imports and fix remaining whitespace / identifier issues. Change-Id: I49474c085b5f4a4b52e4cf90c9705d6a896d4003
* pure black run + flake8Mike Bayer2019-01-061-645/+808
| | | | | | | run black -l 79 against source code, set up for full flake8 testing. Change-Id: I4108e1274d49894b9898ec5bd3a1147933a473d7
* Run batch tests per backendMike Bayer2018-09-021-1/+4
| | | | | | | | | Seeing a new unexpected success in limited scope for mysql, correlating with addition of mariadb 10.3 to CI. This test should be producing db-specific successes/failures to track it more easily Change-Id: Ieacc640768caf98323c5652cb53189da2c43f553
* Drop support for all SQLAlchemy < 0.9Mike Bayer2018-07-131-7/+0
| | | | | | | 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/+52
| | | | | | | | | | 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
* Append table name to batch temp nameMike Bayer2017-10-111-25/+28
| | | | | | | | | | 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
* - keep tuning this mariadb check constraint limitationMike Bayer2017-10-081-2/+3
| | | | Change-Id: I738fbd48a49e78e7103caad5872d592c0691e694
* - more mariadb 10.2 tests that won't workMike Bayer2017-10-061-0/+7
| | | | Change-Id: I7484c653e5f90adb0b25cb74263c99d7bfec5be0
* Accommodate for mariadb 10.2 function reflection styleMike Bayer2017-10-051-0/+4
| | | | | | | | | | | | Fixed bug where server default comparison of CURRENT_TIMESTAMP would fail on MariaDB 10.2 due to a change in how the function is represented by the database during reflection. Also implement mariadb 10.2 checks from SQLAlchemy to skip other CHECK contraint related tests that can't pass. Change-Id: Id77b527d3215d06e2f44a6cddeb77583e5b39101 Fixes: #455
* Ensure primary_key flag unset for PK batch dropMike Bayer2016-12-191-1/+20
| | | | | | | | | 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-6/+31
| | | | | | | | | | | 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
* - adjust boolean no_ck test to not use Boolean typeMike Bayer2016-06-231-1/+5
| | | | | | | to insert a non 0/1 integer; SQLA 1.1 now coerces it to 1/0 Change-Id: I4447547b98a5178c7a1185d5788bfb58ae8c23ee
* - Small adjustment made to the batch handling for reflected CHECKMike Bayer2016-06-011-13/+13
| | | | | | | 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.
* - changelog for #361, fixes #361Mike Bayer2016-03-161-1/+1
| | | | - rename test
* Allow server_default=None for batch operations.Martin Domke2016-03-161-0/+16
|
* - Repaired batch migration support for "schema" types which generateMike Bayer2016-01-221-0/+127
| | | | | | | | | | | | | | | 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