anmolxlight commented on code in PR #66674:
URL: https://github.com/apache/airflow/pull/66674#discussion_r3234770659
##########
airflow-core/src/airflow/utils/db_manager.py:
##########
@@ -189,10 +220,15 @@ def upgradedb(self, to_revision=None, from_revision=None,
show_sql_only=False, u
self._release_metadata_locks_if_needed()
if not current_revision and not to_revision and not
use_migration_files and not show_sql_only:
- self.create_db_from_orm()
- return
+ if self._has_existing_manager_tables():
+ config = self.get_alembic_config()
+ self._stamp_base_revision(config)
+ else:
+ self.create_db_from_orm()
+ return
Review Comment:
I see why it looks setup-related, but the bad behavior is in the generic
manager upgrade path here.
The failing state is: manager-owned tables already exist, but the
manager-specific Alembic version table does not. In that state
`BaseDBManager.upgradedb()` currently treats the DB as empty, calls
`create_db_from_orm()`, and then stamps the manager to head. Since
`metadata.create_all()` is a no-op for existing tables, any migrations that
should alter those existing tables are skipped, but Alembic now records the
schema as current.
This can happen when tables were created before being managed by an external
DB manager, so setup cannot recover once this path stamps head. The fix keeps
the empty-DB fast path unchanged, but for existing manager tables it stamps the
base revision and then lets Alembic run the real migrations to heads.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
