Resolve the following RemovedIn20Warning warnings:
The MetaData.bind argument is deprecated and will be removed in
SQLAlchemy 2.0.
The ``bind`` argument for schema methods that invoke SQL against an
engine or connection will be required in SQLAlchemy 2.0.
We must retain a couple of workarounds to keep sqlalchemy-migrate happy.
This shouldn't be an issue since this library is not compatible with
SQLAlchemy 2.x and will have to be removed (along with the legacy
migration files themselves) when we eventually support 2.x.
Change-Id: I946b4c7926ba2583b84ab95a1fe7aedc6923d9f8
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
Resolve the following RemovedIn20Warning warning:
Passing a string to Connection.execute() is deprecated and will be
removed in version 2.0. Use the text() construct, or the
Connection.exec_driver_sql() method to invoke a driver-level SQL
string.
Change-Id: I44d6bf1ebfaf24f00a21389364456bceaae7c4d1
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
Resolve the following RemovedIn20Warning warnings:
The autoload parameter is deprecated and will be removed in version
2.0. Please use the autoload_with parameter, passing an engine or
connection.
Change-Id: I10e9bbf14706aece2a59ebb5861004c5b852a592
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
Let's take advantage of the features that alembic provides [1]. We use
this opportunity to clean up how we do our base model creation and
remove the downgrade section from the migration script template, since
we don't support downgrades.
[1] https://alembic.sqlalchemy.org/en/latest/autogenerate.html
Change-Id: I18846a5c7557db45bb63b97c7e8be5c4367e4547
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
This wasn't as complicated as feared. We're mostly able to copy-paste
the existing sqlalchemy-migrate migration and simply changes the pattern
of calls from monkey-patched 'create' methods such as:
agent_builds = Table('agent_builds', meta,
sa.Column('created_at', sa.DateTime),
...
mysql_charset='utf8'
)
agent_builds.create()
to explicit alembic APIs like:
op.create_table(
'agent_builds',
sa.Column('created_at', sa.DateTime),
...
mysql_charset='utf8'
)
Reviewers are encouraged to diff the old migration file,
'nova/db/main/legacy_migrations/versions/402_train.py' against the new
one, 'nova/db/main/migrations/versions/8f2f1571d55b_initial_version.py',
to ease their job. The only significant divergences are the removal of
a single reference to the 'migrate_version' table created by
sqlalchemy-migrate, which obviously won't exist in an alembic-only
world, along with some reordering of tables. The latter step is
necessary since Alembic is not smart enough to correctly order the
creation of tables so that tables that reference (via a foreign key) one
or more other tables are created after the table(s) they reference.
Since we now have to create tables using the 'create_table' API as noted
above, rather than by creating a 'Table' instance and calling the
sqlalchemy-migrate-provided 'create' API as we could previously, we must
reorder our calls. The alternative would be to leave the creation of any
'ForeignKeyConstraint' until later but that seems no better and would
arguably be harder to read.
Note that this isn't yet wired up to anything: users can run it manually
but the nova-manage commands we provide are still connected to the
sqlalchemy-migrate commands. This will change shortly when we add shims
to handle the conversion.
Change-Id: I1fa2feaee78213ad81f1889ce54888696f58d98c
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
We have a class of bugs in our current database schema that were
introduced by now-squashed migrations, whereby we applied a new
constraint to a column but forgot to apply the same change to the column
in the shadow table. Currently, we preserve the behavior of these bugs
through use of the 'ALTER' statement. This results in more complex SQL
for the initial migration, however, more importantly, the ALTER
statement is not actually supported by SQLite and the underlying
migration engine must instead mimic behavior by creating a new table
with the updated schema and a temporary name, copy across all data from
the old table to the new table, delete the old table and rename the new
table.
While sqlalchemy-migrate handled this transparently for us, therefore
allowing us to mostly ignore the issue, alembic makes this lack of
support in SQLite explicit by insisting on the 'batch_alter_table'
context manager [1] wrapping any ALTER statements. This is context
manager is "a little tricky" (zzzeek's words, not mine) and is therefore
best avoided. Fortunately, this is easily done through the addition of a
couple of checks within the '_create_shadow_tables' helper that simply
modify the affected columns before creating the table.
[1] https://alembic.sqlalchemy.org/en/latest/ops.html#alembic.operations.Operations.batch_alter_table
Change-Id: Ib3c8ed876791cda96486d43384f7aec0c487fd2f
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
We place these in a 'legacy_migrations' directory, as we will soon be
adding alembic-based migrations in a 'migration' directory.
Change-Id: Ib927e4c48f59a467a913875111ffbf64ffe0de90
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
