On 07/06/2016 10:23 PM, Jon Davidson wrote:
On Wed, Jul 6, 2016, at 12:25 PM, Mike Bayer wrote:
so yeah this use case is a big deal now, because all of openstack wants
to do it.
However in openstack, they at least know what version the target schema
is at, so while they need to run code that talks to the "old" and "new"
columns simultaneously, the code itself doesn't have to guess because
it's tied to a "version" of the schema that may include only the old,
the old and new, or only the new.
That is, they have a multi-step versioning approach, if that makes sense.
Interesting. Do you know if this is written up anywhere (the
SQLAlchemy-specific parts of it, I mean)? I may be able to work with
this approach.
they haven't been writing much up about the SQLAlchemy specific parts
:). Mostly, Alembic is useful because it features branches now, so the
migrations themselves are organized into "expand" and "contract"
branches that are run at totally different times (expand == add new
columns, contract == remove old columns). They then have to somehow
make it work out such that when you install a new version of the
software, you run "expand", then that software reads both the old and
new columns (which pretty much is done the most tedious way possible,
they map both explicitly :( ). The app must read and populate both
columns in all cases as older versions of the app might be running
elsewhere which are not reading the new column and are still populating
the old column. Once all the apps are upgraded to read both columns,
additional jobs are run to actually copy any remaining data from old to
new. Now everyone's on the same version, both columns exist. Time to
upgrade to the *next* version. Now you can run the "contract" branch
for that previous version, and you run "expand" for the *new* version
and start the whole thing over again.
It's totally a mess, but there's not *too* many other ways to do it.
One way to possibly reduce the "we have to read/write both columns"
issue is to use triggers to replicate any data movement on the old or
new columns rather than having the application do it (in fact the
management of these triggers would likely be piggybacked onto the
migration system itself). Nobody has tried that yet, though.
--
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sqlalchemy+unsubscr...@googlegroups.com.
To post to this group, send email to sqlalchemy@googlegroups.com.
Visit this group at https://groups.google.com/group/sqlalchemy.
For more options, visit https://groups.google.com/d/optout.
