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.
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
