> It will likely work fine if we do some "consistency check" when FAB is
used
as "external_db_manager" - in this case, possibly airflow should refuse to
start (and show helpful message) if there is a consistency problem between
what FAB expects and what is stored in alembic DB. This should handle a
+1 from my side. But compared to expose explicit CLI for migrations for
providers I'd prever to have DB stuff upgrade and downgrade implicitly
called/executed/delegated to the provider package. Would it not be good
to "just register" the DB created/upgrade/downgrade/reset" hooks for
each provider
One thing to keep in mind is that this sets the precedent for providers
managing their own db "stuff". So while it may be rare for FAB, we should
look at this from a general "provider with db stuff" perspective. And other
use cases could have more frequent changes.
Overall I also think this strike
I think that is a good compromise between "full" integration and "optional
integration". And as long as we document and explain it with some example
scenarios ("what to do if you upgrade the FAB provider separately") - this
should be fine.
It will likely work fine if we do some "consistency check"
