On Jul 12, 2010, at 7:09 PM, Steven Wei wrote: > How do you deal with creating new tables in this scenario? Right now > I'm importing the model object and calling create() on the table like > this: > > from manager.models import Account > > def upgrade(migrate_engine): > metadata.bind = migrate_engine > Account.__table__.create() > > def downgrade(migrate_engine): > metadata.bind = migrate_engine > Account.__table__.drop() > > This avoids having to duplicate the table definition when using the > declarative syntax, but I can imagine some edge conditions causing > problems if Account is modified later on.
So the notion I had below issues a create_all(), which looks up all tables in the DB and creates any that don't exist. But its true, this approach doesn't give you a full blown upgrade/downgrade to zero path. If using create(), you can at least add checkfirst=True so that if the table is already there, it passes. That way you can run individual migrations that create tables, and also the setup-app still works with the create_all() + migrations approach. > > > On Jul 9, 11:03 pm, Michael Bayer <[email protected]> wrote: >> On Jul 10, 2010, at 1:08 AM, Steven Wei wrote: >> >> >> >>> On Jun 17, 4:00 am, Francisco Souza <[email protected]> >>> wrote: >>>>> But do I do this? Part of the problem is that I don't know of a way >>>>> to generate tables other than create_all() (or drop_all()) when using >>>>> declarative syntax. Is there another way? >> >>>> Hi Shane :) >> >>>> When you bind your declarative base to a metadata, the "metadata" object >>>> has >>>> a attribute called "tables", wich is a dict with all tables containeds in >>>> this metadata. So, you can do a create for a single table easily. >> >>>>>>> Base.metadata.tables['test_case'].create(engine) >> >>>> You can call it on your upgrade function inside the migration module. >> >>> Isn't this incredibly problematic if you need to change the model >>> definition later? What if you need to add a column to this table in a >>> new migration later on? >> >>> It will work on your existing databases, but if you run through your >>> migrations on a fresh database, you'll have a problem because the >>> first migration created the table with the extra column in place, and >>> the second migration won't be able to add the column again. >> >>> The sqlalchemy-migrate docs suggest you copy and paste Table >>> definitions to avoid this behavior (ugh). But when you're using >>> DeclarativeBase you don't even have any Table definitions to copy >>> from! >> >> the sqlalchemy-migrate docs are insane in this regard. Use reflected >> tables in your migrations scripts, that way you don't have to worry at all >> about what the status of the table is other than the thing you are >> migrating. When I eventually get around to releasing Alembic, you won't >> even have to reflect anything, you can just specify the alterations you care >> about. >> >> >> >>> Is there any way around this other than not running migrations when >>> creating new databases (and instead sticking with create_all() >>> directly)? >> >> i havent read the thread here, but if the issue is, how to create new >> databases when you're up to version 67 in your migrations, issue the >> create_all(), then create the migration table, then set the version to the >> most recent. Code looks like this: >> >> from migrate.versioning.api import version_control, version, upgrade >> from migrate.versioning.exceptions import DatabaseAlreadyControlledError >> >> Base.metadata.create_all(bind=engine, checkfirst=True) >> >> # setup migrate versioning table if not present >> try: >> latest_version = version("migrate") >> version_control(url, "migrate", version=latest_version, echo=True) >> except DatabaseAlreadyControlledError: >> log.info("migrate table already present") >> >> # do any migrate upgrades pending... >> upgrade(url, "migrate", version=latest_version, echo=True) >> >> my apologies if this is not the question being asked. > > -- > You received this message because you are subscribed to the Google Groups > "sqlalchemy" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/sqlalchemy?hl=en. > -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
