[openstack-dev] [Ceilometer] Need help with Alembic...
Herndon, John Luke (HPCS - Ft. Collins)
john.herndon at hp.com
Mon Aug 26 19:40:41 UTC 2013
It looks there is an error in the migration script that causes it to abort:
AttributeError: 'ForeignKeyConstraint' object has no attribute 'drop'
My guess is the migration runs on the first test, creates event types
table fine, but exits with the above error, so migration is not
"complete". Thus every subsequent test tries to migrate the db, and
notices that event types already exists.
On 8/26/13 1:15 PM, "Jay Pipes" <jaypipes at gmail.com> wrote:
>I just noticed that every single test case for SQL-driver storage is
>executing every single migration upgrade before every single test case
>instead of simply creating a new database schema from the models in the
>current source code base using a call to sqlalchemy.MetaData.create_all().
>This results in re-running migrations over and over again, instead of
>having dedicated migration tests that would test each migration
>individually, as is the case in projects like Glance...
>Is this intentional?
>On 08/26/2013 02:59 PM, Sandy Walsh wrote:
>> I'm getting the same problem with a different migration (mine is
>> complaining that a column already exists)
>> I've compared it to the other migrations and it seems fine.
>> On 08/26/2013 02:34 PM, Jay Pipes wrote:
>>> Hey all,
>>> I'm trying to figure out what is going wrong with my code for this
>>> I had previously added a sqlalchemy-migrate migration script to add an
>>> event_type table, and had that working, but then was asked to instead
>>> use Alembic for migrations. So, I removed the sqlalchemy-migrate
>>> migration file and added an Alembic migration .
>>> Unfortunately, I am getting the following error when running tests:
>>> OperationalError: (OperationalError) table event_type already exists
>>> u'\nCREATE TABLE event_type (\n\tid INTEGER NOT NULL, \n\t"desc"
>>> VARCHAR(255), \n\tPRIMARY KEY (id), \n\tUNIQUE ("desc")\n)\n\n' ()
>>> The migration adds the event_type table. I've seen this error occur
>>> before when using SQLite due to SQLite's ALTER TABLE statement not
>>> allowing the rename of a column. In the sqlalchemy-migrate migration, I
>>> had a specialized SQLite migration upgrade  and downgrade 
>>> but I'm not sure how I am supposed to handle this in Alembic. Could
>>> someone help me out?
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 5443 bytes
Desc: not available
More information about the OpenStack-dev