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 <mailto:sqlalchemy-alembic+unsubscr...@googlegroups.com>. 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.
