Open Stack

On 5/21/15 2:50 PM, Mike Bayer wrote:
>
> Put another way, if I want to do a migration that someday, "over 
> time", eventually, etc., will drop the "widget_status" table and merge 
> it into the "widget" table, how do I write the "get_widget()" DB API 
> call ?     Same for just dropping a column.   If we have to write code 
> that will return the value of the old table / old column while it 
> exists, how does that part work?   Somewhere, there has to be code 
> that in one case says: "query(Widget).join(WidgetStatus)" and in other 
> case says "query(Widget)".   You have to maintain *both* SQL queries 
> at the same time?
OK I guess it is this: "Kilo queries Widget JOIN WidgetStatus while 
Liberty queries just Widget" - e.g. the two versions of the query are 
just in two different releases of the application.    You need to run 
exclusively the old sqlalchemy/api.py version of the code before 
"contract" is run, that is, the new API / nova.objects runs against the 
old model code.

OK!   let me chew on that.


The good news is, online schema migrations does not invalidate all of 
Alembic's approach.   Version files and fixed schema states are still 
essential for mere mortals.   Openstack projects that aren't using 
oslo.objects will still need them.