On Monday, August 19, 2019 at 9:58:19 AM UTC+10, Mike Bayer wrote: > > > > On Sun, Aug 18, 2019, at 6:50 PM, Scott wrote: > > Looking to use Alembic to manage migrations. > > We currently have different database names in each environment, so for > dev, test and prod we have db_dev, db_test and db_prod respectively. > > Is this database naming scheme going to be compatible with Alembic or am I > better off looking to drop the environment suffix? > > > these are three different URLs and if the concern is putting them into one > alembic.ini file, easy enough using separate sections: > https://alembic.sqlalchemy.org/en/latest/cookbook.html#run-multiple-alembic-environments-from-one-ini-file > > though usually staging and production DBs have a password you're looking > to keep private, and you'd have a separate alembic.ini on your staging and > prod servers. but either way it's all doable >
Thanks for your reply. The databases in question will in fact contain the same schema, table, view, etc. objects. We develop in dev, then promote code and database changes to test and then on to prod. This seems like a pretty straightforward use case for Alembic; each DB will have its own version and when we promote code from dev to test and then on to prod the relevant head would be retrieved from git (along with application code) and can be applied to the target database in order to bring it up to the correct version. In our case however, with manual deployment we included a variable in the database name and change this per environment. So when we promote code we need the changes we made to db_*dev*.schema1.table1 to be made to db_*test*.schema1.table1. I think this is different concept to the what "sections" provides. If I was going to manually create the upgrade/downgrade scripts every time I could continue to use a variable to compute the database name, but I could never use autogenerate as this would bring in a specific database name and I would no longer be able to move my code between environments. I suspect the safest approach will be if we drop the environment suffix from our table names. This will be easier all around. Happy to receive any further advice others may have to offer. Wondering for example if *render_item* can be used. Cheers, Scott -- You received this message because you are subscribed to the Google Groups "sqlalchemy-alembic" group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy-alembic+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sqlalchemy-alembic/878a46b2-9e3c-4f40-8369-dd05f45e872f%40googlegroups.com.
