potiuk edited a comment on pull request #18439: URL: https://github.com/apache/airflow/pull/18439#issuecomment-925375399
The more I think about it, the more I like the idea of always running the migration at start of everything. I think for quite a while we neglected the fact, the db structure can get desynchronized from code, but I cannot imagine ANY situation including the dev where DB should be in a different version than latest airflow migration in the code. There is not a single case I can think of that this might be better than allowing for desynchronisation. This is "db as a code" to the fullest. The only edge case is of course when you are working on a new migration (which is extremely rare actually) - but even there eve if you try to implement and run/rerun and fix the migration you would rather just test the migrations not the airflow and if you wan to iterate on it you have to play with alembic command-line rather than with airflow worker/scheduler/webserver. And even there, it's extremely easy to add ``--skip-db-migrations`` to all the components of airflow. There is one potential problem - the migration lock is not implemented for MsSQL. But assuming that is done, is there any reason we do NOT want to run migration for all components when they start ? Is there any particular reason we would not want to run the migrations? Any risks involved in doing so ? I thought hard about it and I cannot think a single reason why we would not want to do it. -- 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]
