Description

I was looking into alembic to figure out whether i could use it on my project, but ended up finding out some strange behavior.

As my project is using multiple databases, I followed the documentation to prepare alembic environment and tried to generate 'initial' migration revision file with current database schema.

However, strangely, the revision file generated contained all the tables from every other database on single database upgrade/downgrade function. And as expected, running the migration on clean database using the revision file made all the tables to be created on single database.

How to Reproduce the Problem

Here is the minimized test case for reproducing what I explained above.

Conclusion

There is a possibility that I might have completely misunderstood the proper usage of alembic. If so, please feel free to let me know. Otherwise, I would really appreciate it if you look into the case above whether it is a bug or expected behavior.

This comment has been minimized.

Fixed a regression 0.8 whereby the "multidb" environment template
failed to produce independent migration script segments for the
output template. This was due to the reorganization of the script
rendering system for 0.8. To accommodate this change, the
:class:.MigrationScript structure will in the case of multiple
calls to :meth:.MigrationContext.run_migrations produce lists
for the :attr:.MigrationScript.upgrade_ops and
:attr:.MigrationScript.downgrade_ops attributes; each :class:.UpgradeOps
and :class:.DowngradeOps instance keeps track of its ownupgrade_token and downgrade_token, and each are rendered
individually.
fixes #318