On Sun, Dec 23, 2018 at 7:40 AM Nikola Radovanovic <nikola...@gmail.com> wrote: > > Hi, > First of all, thank you for these great tools making my developer's life so > much easier and pleasant. > > I need suggestion/help on how to utilize multi-tenant schemes in Alembic. I > have few projects under the development that requires multi-tenancy in such > way that there will be some common/shared data stored in general(public) > schema shared by multiple schemes. In each schema there is same set of tables > - no exception. I followed some docs and managed to find this one (but its > rather old and not sure if it is still valid). Also, using some other links > (cant recall which exactly) I managed to find a similar solution (see the > attached env.py), but in which case, there is alembic migration version table > in each schema. This is not big issue, but it left me with the feeling of > incompleteness, like I am missing something important. I would like to use > pure SqlAlchemy/Alembic without Flask.
hi there - the env.py you attached is mostly the right idea, I see the Flask import which I would think you can remove, if you know what it is you need from the current_app.extensions['migrate'].configure_args map, I don't know what they put in there so maybe just add a print() statement to see what they are adding and we can go over what options might be useful. you do want the alembic version table to be local per schema because in theory you can add a new tenant which is now by definition at the base version, which means different schemas can be on different versions simultaneously. if you wanted one alembic_version table for the whole thing you'd need to devise a way to get each upgrade() method in an individual revision to run across all tenants, which can be done but is more complicated and kind of more scary because you either need one giant transaction for all the tenants, or if you are committing per schema then you can easily have a situation where things are out of sync, e.g. alembic_version table does not represent the actual state of all tenants. for the "public" schema it's likely best to keep that as a totally separate set of version files, so that an individual Alembic version script deals only with one kind of database and has just a single upgrade() / downgrade() method. if you wanted to write version scripts that can affect both the public and all the tenant schemas you'd again need to add some more switching around within env.py as we see in https://github.com/sqlalchemy/alembic/blob/master/alembic/templates/multidb/env.py#L104. > > Anyone has a suggestion? > > Thank you all in advance > > -- > 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. -- 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.
