Cannot downgrade to database revision 4070806f6972 in PostgreSQL
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Barbican |
Won't Fix
|
Undecided
|
Unassigned |
Bug Description
When trying to downgrade to revision 4070806f6972 I get the following stack trace:
2015-01-29 13:56:40.983 12113 ERROR __main__ [-] Problem trying to execute Alembic commands
2015-01-29 13:56:40.983 12113 TRACE __main__ Traceback (most recent call last):
2015-01-29 13:56:40.983 12113 TRACE __main__ File "bin/barbican-
2015-01-29 13:56:40.983 12113 TRACE __main__ dm.execute()
2015-01-29 13:56:40.983 12113 TRACE __main__ File "bin/barbican-
2015-01-29 13:56:40.983 12113 TRACE __main__ args.func(args)
2015-01-29 13:56:40.983 12113 TRACE __main__ File "bin/barbican-
2015-01-29 13:56:40.983 12113 TRACE __main__ commands.
2015-01-29 13:56:40.983 12113 TRACE __main__ File "/home/
2015-01-29 13:56:40.983 12113 TRACE __main__ alembic_
2015-01-29 13:56:40.983 12113 TRACE __main__ File "/home/
2015-01-29 13:56:40.983 12113 TRACE __main__ script.run_env()
2015-01-29 13:56:40.983 12113 TRACE __main__ File "/home/
2015-01-29 13:56:40.983 12113 TRACE __main__ util.load_
2015-01-29 13:56:40.983 12113 TRACE __main__ File "/home/
2015-01-29 13:56:40.983 12113 TRACE __main__ module = load_module_
2015-01-29 13:56:40.983 12113 TRACE __main__ File "/home/
2015-01-29 13:56:40.983 12113 TRACE __main__ mod = imp.load_
2015-01-29 13:56:40.983 12113 TRACE __main__ File "/home/
2015-01-29 13:56:40.983 12113 TRACE __main__ run_migrations_
2015-01-29 13:56:40.983 12113 TRACE __main__ File "/home/
2015-01-29 13:56:40.983 12113 TRACE __main__ context.
2015-01-29 13:56:40.983 12113 TRACE __main__ File "<string>", line 7, in run_migrations
2015-01-29 13:56:40.983 12113 TRACE __main__ File "/home/
2015-01-29 13:56:40.983 12113 TRACE __main__ self.get_
2015-01-29 13:56:40.983 12113 TRACE __main__ File "/home/
2015-01-29 13:56:40.983 12113 TRACE __main__ step.migration_
2015-01-29 13:56:40.983 12113 TRACE __main__ File "/home/
2015-01-29 13:56:40.983 12113 TRACE __main__ op.execute( 'ALTER TABLE container_secret DROP PRIMARY KEY, ADD PRIMARY KEY(`container_
2015-01-29 13:56:40.983 12113 TRACE __main__ File "<string>", line 7, in execute
2015-01-29 13:56:40.983 12113 TRACE __main__ File "/home/
2015-01-29 13:56:40.983 12113 TRACE __main__ execution_
2015-01-29 13:56:40.983 12113 TRACE __main__ File "/home/
2015-01-29 13:56:40.983 12113 TRACE __main__ self._exec(sql, execution_options)
2015-01-29 13:56:40.983 12113 TRACE __main__ File "/home/
2015-01-29 13:56:40.983 12113 TRACE __main__ return conn.execute(
2015-01-29 13:56:40.983 12113 TRACE __main__ File "/home/
2015-01-29 13:56:40.983 12113 TRACE __main__ return meth(self, multiparams, params)
2015-01-29 13:56:40.983 12113 TRACE __main__ File "/home/
2015-01-29 13:56:40.983 12113 TRACE __main__ return connection.
2015-01-29 13:56:40.983 12113 TRACE __main__ File "/home/
2015-01-29 13:56:40.983 12113 TRACE __main__ compiled_sql, distilled_params
2015-01-29 13:56:40.983 12113 TRACE __main__ File "/home/
2015-01-29 13:56:40.983 12113 TRACE __main__ context)
2015-01-29 13:56:40.983 12113 TRACE __main__ File "/home/
2015-01-29 13:56:40.983 12113 TRACE __main__ exc_info
2015-01-29 13:56:40.983 12113 TRACE __main__ File "/home/
2015-01-29 13:56:40.983 12113 TRACE __main__ reraise(
2015-01-29 13:56:40.983 12113 TRACE __main__ File "/home/
2015-01-29 13:56:40.983 12113 TRACE __main__ context)
2015-01-29 13:56:40.983 12113 TRACE __main__ File "/home/
2015-01-29 13:56:40.983 12113 TRACE __main__ cursor.
2015-01-29 13:56:40.983 12113 TRACE __main__ ProgrammingError: (ProgrammingError) syntax error at or near "PRIMARY"
2015-01-29 13:56:40.983 12113 TRACE __main__ LINE 1: ALTER TABLE container_secret DROP PRIMARY KEY, ADD PRIMARY K...
2015-01-29 13:56:40.983 12113 TRACE __main__ ^
2015-01-29 13:56:40.983 12113 TRACE __main__ 'ALTER TABLE container_secret DROP PRIMARY KEY, ADD PRIMARY KEY(`container_
2015-01-29 13:56:40.983 12113 TRACE __main__
This might be working in mysql but it certainly does not in postgresql.
Changed in barbican: | |
assignee: | nobody → Juan Antonio Osorio Robles (juan-osorio-robles) |
summary: |
- Cannot downgrade to database revision 4070806f6972 + Cannot downgrade to database revision 4070806f6972 in PostgreSQL |
Changed in barbican: | |
assignee: | nobody → Giovanni Torres (gitorres) |
Changed in barbican: | |
status: | New → In Progress |
Changed in barbican: | |
status: | In Progress → New |
assignee: | Giovanni Torres (gitorres) → nobody |
I think the issue is that some of the alembic version files are doing more direct to SQL calls than going thru the ORM...so as you say they may work in mysql but not in postgresql. We've talked of using Grenade gate jobs to help with the migration gut checking, but I'm not sure if that includes testing via differing database types?