search

qizhiyi / sqlalchemy-migrate

Automatically exported from code.google.com/p/sqlalchemy-migrate
MIT License
0 stars 0 forks source link

migrate.changeset implicity imported during upgrade but not downgrade #51

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago 
What steps will reproduce the problem?
1. Write upgrade and downgrade procedures that call methods that are
ordinarily patched into SQLALchemy classes, e.g. Column.drop.
2. Don't explicity import migrate.changeset.
3. Execute the upgrade, then the downgrade.

What is the expected output? What do you see instead?
Instead of the downgrade working, you'll see something like AttributeError:
'Column' object has no attribute 'drop', because 'drop' or some other
sqlalchemy-migrate method hasn't been patched in.

What version of the product are you using? On what operating system?
sqlalchemy-migrate 0.5.2
SQLAlchemy 0.5.2
PostgreSQL 8.3
OS X 10.5.6

I ran across this issue when writing a downgrade for an upgrade that only
added a column to a table.  The downgrade didn't work, and after some
debugging I discovered that Column.__bases__ hadn't been modified.  So, I
imported migrate.changeset, which patched Column, which fixed the downgrade.

It doesn't seem like migrate.changeset should have to be explicitly
imported for downgrades but not for upgrades (Column.create worked in the
upgrade without the import).  The docs say that importing migrate.changeset
adds new methods, but in this case I didn't need to for an upgrade, which
led to breakage in the downgrade.

Original issue reported on code.google.com by chris%no...@gtempaccount.com on 11 Mar 2009 at 11:05

GoogleCodeExporter commented 8 years ago 
Oops! Correction: after running the upgrade independently instead of after a few
others that imported migrate.changeset, it also doesn't work without importing
migrate.changeset.  So, nothing is being imported implicitly.

However, it would be confusing for imports in one migration affect the 
execution of a
later one.  The second may work after the first but not independently, as in 
this
case, or the downgrade may not work because the scripts are loaded in reverse 
order,
etc.  I'm not sure if this is what is happening, but I can't come up with any 
other
explanation.

Original comment by chris%no...@gtempaccount.com on 11 Mar 2009 at 11:27

GoogleCodeExporter commented 8 years ago

Original comment by jan.ditt...@gmail.com on 14 Feb 2011 at 7:11