Permit airflow db migrate -r with an empty database
#59205
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
To allow
airflow db migrateto respect its-roption when run against an empty database, we need to supply an initial migration which creates the database in the state expected by the existing 0001 migration.This commit:
upgradedbto always run a migration-based upgrade rather than a direct reflection of table metadata whento_revisionis supplied.add_default_pool_if_not_existsto not assume that it's running with the latest database schema.My primary motivation here is to make it easy to prepare an Airflow database with a schema at any point in the migration history, for the purposes of testing and improving migrations. This specifically came up in the context of identifying that the
sqlitedialect migration for0042_3_0_0_add_uuid_primary_key_to_task_instance_.pyis quite broken.I'm not entirely clear on what the status is of theAfter discussing with @ashb I've left them in for now, as this a) simplifies handling migrationab_*tables, and whether they should or should not be included here. The difficulty of omitting them altogether is that they are referenced -- albeit only once -- by subsequent migrations: see migration 0028.0028, and b) more accurately reflects the state the database would be in if it had truly been migrated up from 2.x.To assess whether this base migration results in the same end result as simply running
initdb, I've been running a script something like this to print the schema as seen bysqlalchemyin a canonicalized order:Script to print a canonicalized schema:
print_tables.pyHere is the diff when running this on main:
I'd greatly appreciate any feedback on whether this is wanted/helpful -- my view is that the
-roption todb migrateshould always be respected -- and if so, what if any changes are needed for the handling of the mentioned tables.