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.
On Jul 9, 11:03 pm, Michael Bayer <mike...@zzzcomputing.com> wrote:
> On Jul 10, 2010, at 1:08 AM, Steven Wei wrote:
>
>
>
> > On Jun 17, 4:00 am, Francisco Souza <franci...@franciscosouza.net>
> > 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 sqlalch...@googlegroups.com.
To unsubscribe from this group, send email to
sqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en.
