On 09/29/2016 11:01 PM, Wesley Weber wrote:
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).
I think what you can do on your end is organize your alembic revisions
into major versions of your project. that way someone can run your
upgrades to the end of the 1.x.x series, you can backport migrations
into 1.x.x, etc. a consuming api could manage their own migrations
among your siloed versions. I haven't stepped through the details of
this but Openstack Neutron has things set up this way, because they
support external plugins with their own migrations.
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
<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
<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.
