if I understand your description correctly you include your
declarative_base model classes into your migration scripts. You should
not do this.
You can reference existing tables in migration scripts via schema
reflection but using declarative_base gets a bit more complicated.
Maybe you get some more ideas from the migrate-users group (added to
discussion).
Regards
Jan Dittberner
2011/6/4 Ryu Ishimoto <r...@midokura.jp>:
> Hi, I just recently started looking into using sqlalchemy migration,
> and I'm having difficulty understanding how it works with
> declarative_base. The problem is I don't quite understand how
> migration COULD handle the situation in which the model class
> definition changes in certain scenarios.
>
> For example, let's say if we have:
>
> '001_create_users_table' that creates users table.
> '002_create_addresses_table' that creates addresses table, and adds
> 'address_id' column in the users table which is a foreign key
> reference to the addresses table.
>
> When creating 002_create_addresses_table, using declarative_base, you
> would have to also modify the class definitions to include Address
> class and address_id attribute in User class referring to the Address
> class.
>
> But then what happens if a user wants to run these migration scripts
> to build the database from scratch? 001_create_users_table would look
> at the User class and finds that there is 'address_id' column
> referring to Address table that hasn't even been created in the
> database yet.
>
> Is this a case that sqlalchemy migrate just cannot handle? Do I need
> to not use declarative_base and define Tables in the migration? I am
> new to sqlalchemy, so perhaps I'm missing something fundamental.
>
> Thanks in advance!
>
> Ryu
--
Jan Dittberner
Software Architect - Debian Developer