allow multiple metadata objects for autogenerate

[sqlalchemy-bot]

Migrated issue, originally created by Michael Bayer (@zzzeek)

[sqlalchemy-bot]

buddyteal7 wrote:

It is very common to have multiple models and many tables. This feature seems quite important. I'm surprised more people haven't run in to this issue.

[sqlalchemy-bot]

Michael Bayer (@zzzeek) wrote:

Currently I'm working around it roughly like this:

our_metadata = MetaData()
for metadata in (m1, m2, m3):
	for t in metadata.tables.values():
		 if _your_check_here(t):
		 	t.tometadata(our_metadata)

[sqlalchemy-bot]

buddyteal7 wrote:

I have a few questions about your work around:

Are you using this work around in env.py and setting the value of target_metadata? Or is this used somewhere separate?

Where is MetaData() being defined?

t.tometadata(our_metadata) - not sure how this is working or what is actually getting set.

I really like alembic and would love to get it working with multiple models.

[sqlalchemy-bot]

Michael Bayer (@zzzeek) wrote:

this is in env.py. MetaData is defined within the application's model, then the local "our_metadata" is local to env.py. tometadata() is here: http://docs.sqlalchemy.org/en/rel_0_8/core/schema.html?highlight=tometadata#sqlalchemy.schema.Table.tometadata .

[sqlalchemy-bot]

buddyteal7 wrote:

Got it. Thanks for taking the time to clarify, much appreciated.

[sqlalchemy-bot]

Changes by Michael Bayer (@zzzeek):

• added labels: autogenerate - detection

[sqlalchemy-bot]

Changes by Michael Bayer (@zzzeek):

• set milestone to "tier 1"

[sqlalchemy-bot]

Jon Skulski (@jskulski) wrote:

Well one, thanks for alembic and SQLalchemy :) Two, this issue does seem very important.

I'm exploring options at work (essentially SQLAlchemy vs Alembic) and this issue caused me to drop Alembic. I'm glad I found the work around and would suggest that it be placed in the tutorial. I'd imagine 99% of people want to use more than one object with alembic.

Thanks!

[sqlalchemy-bot]

Jon Skulski (@jskulski) wrote:

I'm a bit confused now. Because I tried with one of my models, and autogenerated against a blank sql database and it generated (seemingly) all the tables and columns I would need, even ones it has no relation too.

Maybe it's the structure of the app I've inherited, and also my own confusion. Do we actually need to supply multiple metadata?

[sqlalchemy-bot]

Michael Bayer (@zzzeek) wrote:

it's not a feature that comes up too much. most folks seem to have a single declarative Base for their app with a MetaData and that's it.

in your case it depends on where you are storing all your Table objects - in one MetaData or several.

[sqlalchemy-bot]

Jon Skulski (@jskulski) wrote:

Mike,

Thank you for the reply. My comments were due to my misunderstanding. I was under the impression that you were using a per Table metadata. You can use the database metadata.

So now I have

from myapp import db
target_metadata = db.metadata

where I thought it had to be a specific model (target_metadata = model.metadata) and manually updated in step with code changes. Not the case!

Hopefully, if anyone is suffering from the same delusions this will help.

Thanks again!

[sqlalchemy-bot]

Dominik Czarnota (@disconnect3d) wrote:

Could you guys at least add an example into tutorial that having more then one model one can do:

models.py file:

from sqlalchemy.ext.declarative import declarative_base

Base = declarative_base()

class Model1(Base):
    ...

class Model2(Base):
    ...


metadata = Base.metadata

env.py file:

from models import metadata
target_metadata = metadata

?

[sqlalchemy-bot]

Michael Bayer (@zzzeek) wrote:

@czarnot the models.py you illustrate there has just one MetaData object. http://alembic.readthedocs.org/en/latest/autogenerate.html illustrates this.

[sqlalchemy-bot]

Pankaj Lal wrote:

Any chance, that this is going to be fixed any time soon.

See my question here.

http://stackoverflow.com/questions/38878887/handling-multiple-models-py-with-alembic

[sqlalchemy-bot]

Michael Bayer (@zzzeek) wrote:

@prlal I dont know the answer to that question. the default logging goes to stdout and should illustrate every table its seeing. I'd check that these tables don't already exist in the database.