Yes, I thought more about this and I am essentially exposing the database structure as a public interface. Therefore, I should not make any backwards-incompatible changes between non-major versions.
When there is a backwards-incompatible change in say, v1.x.x to v2.0.0, is there a way to coordinate this? Or would you just instruct ops to run the migrations in a specific order (e.g. update all the plugins to the last 1.x version, which might drop foreign key constraints, then upgrade the main project, then upgrade the plugins to the 2.x version which creates the new constraints). On Thursday, September 29, 2016 at 9:46:59 PM UTC-4, Mike Bayer wrote: > > > > On 09/29/2016 07:52 PM, Wesley Weber wrote: > > I have an uncommon use case that might or might not be supported (or > > even a good idea): > > > > I have a main, independent project with its own tables. I would like to > > keep track of migrations of its database. I will also have several > > "plugin" projects, which can add functionality to the main software. > > These may create and manage their own tables, and the main project need > > not know about them. They may not even share the same source tree. > > this is actually a common use case. > > > However, I would like to support referential integrity in the tables > > created by the plugin projects (e.g., there might be a "users" table in > > the main project, and the plugin might add its own "users_extra_info" > > table referencing the "users" table). > > > > I know how to have the plugin projects use their own alembic folder and > > use a different alembic_version table, but what happens when the main > > project undergoes a migration that breaks referential integrity with the > > plugin projects? (the "users" table changes, violating foreign keys in > > "users_extra_info" from another project, for example). Is there a way to > > handle this? Alternatively, is this not a good design pattern? > > that's actually up to how you advertise your model for plugin authors. > A foreign key constraint typically refers to the primary key of a target > table, or in less common cases towards columns that are inside of a > UNIQUE constraint. You'd not want to change around those columns if > your plugin authors are making FKs towards them. or if you want to > change them, your plugin authors would have to know this. You might > want to use a semantic versioning scheme where you don't make any such > changes within minor versions, and have your plugin authors target > towards a ceiling version so that their plugins aren't broken by such > changes. > > > > > > > > Thanks > > > > -- > > 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 > <javascript:> > > <mailto:sqlalchemy-alembic+unsubscr...@googlegroups.com <javascript:>>. > > For more options, visit https://groups.google.com/d/optout. > -- 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. For more options, visit https://groups.google.com/d/optout.
