potiuk commented on pull request #18439: URL: https://github.com/apache/airflow/pull/18439#issuecomment-925371273
> If we do this, a nob to override the behaviour would be even more necessary. Also, the logic needs to be able to handle cases where the current db state is _in the future_, i.e. say I migrate to latest, `git checkout 2.1.0`, and run `./breeze start-airflow`. I thought a bit about it and I believe the dev environment is not a problem at all. Moreover, it might be pretty handy for development case. For breeze you have `stop` command that wipes out the DB volumes., and i use it rather often when I am switching branches. Alternatively you can also run `./breeze start-airflow` with `--db-reset` flag (which I often use as well) which will run `airflow db reset` as part of the entrypoint_ci before attempting to run airflow.. And to be honest most people even if they develop stuff don't actually switch to old versions - it;s mainly those few committers who either are involved in release management or analysing some strange bugs. But still even in the case you described - just failing if the current db migration is unknown to your version of airflow - would be really handy to notify the developer that the db needs some action. Otherwise the errors you can see might be rather strange. It did happen to me several times that I was scratching my head what's going to only find out that I had an old (or new) db structure. So I see such migration check run at start as pretty useful thing also during development as a consistency check (especially that in Breeze we can even get a bit different error messages to instruct the new developers that they should run `./breeze stop.` or `--db-reset` -- 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]
