Flask-Migrate: column addition / removal apparently undetected, tables recreated instead

Question

I'm using Flask-Migrate in a Flask application with a Postgresql backend. The problem is that after making a change to my models, say a column addition or removal, in any revision or migration that I have tried I always get results along the lines of

INFO  [alembic.autogenerate.compare] Detected added table u'foo'

and every script in migrations/versions contains code for the creation of tables, e.g.

def upgrade():
    ### commands auto generated by Alembic - please adjust! ###
    op.create_table('foo',
    ...
    )
    ### end Alembic commands ###

I was expecting something like

INFO  [alembic.autogenerate.compare] Detected added column u'foo.name'

and

def upgrade():
        ### commands auto generated by Alembic - please adjust! ###
        op.add_column('foo', sa.Column('name', ...
        )
        ### end Alembic commands ###

I'm following the instructions given in this blog. The relevant settings are as follows:

    ### __init__.py
    import ...
    from flask.ext.script import Manager
    from flask.ext.migrate import Migrate, MigrateCommand

    app = Flask(__name__)
    app.config.from_object('config')
    db = SQLAlchemy(app)
    db.metadata.schema = app.config['DB_SCHEMA']
    migrate = Migrate(app, db)
    manager = Manager(app)
    manager.add_command('db', MigrateCommand)
    ...
    import myapp.models

    ###  models.py
    from myapp import db

    class Foo(db.Model):
        id = db.Column(db.Integer, primary_key = True)
        name = db.Column(db.String(50), nullable=False)

I followed some of the suggestions given in these questions: (Alembic/Flask-migrate doesn't recognise database structure) and (No changes detected in Alembic autogeneration of migrations with Flask-SQLAlchemy) with no luck whatsoever.

Any idea what I'm doing wrong?

Thanks in advance.

Solved

I just discovered the problem. I like to use DB schemas, and I was doing this

    db.metadata.schema = app.config['DB_SCHEMA']

It seems alembic somehow is not aware of the inherent scope of the schema and therefore it recreates the tables all the time. Sort of: there is no table foo - in the outermost, global 'schema' or scope - so I have to create that table. This was happening even after the very first migration correctly created the table. Of course, execution of a second migration unsurprisingly produced

    sqlalchemy.exc.ProgrammingError: (ProgrammingError) relation "foo" already exists

I just dropped the above declaration and now I see the changes coming out properly.

    INFO  [alembic.autogenerate.compare] Detected added column 'foo.name'

I don't know if I have to do something special to support schemes. Perhaps this is just an unsupported feature.