On 08/30/2016 09:57 AM, Clint Byrum wrote:
As someone else brought up, this is an unnecessarily bleak view of how database
migrations work.
We aren't talking about database migrations. We are talking about
*online* database migrations, where we would like both the *old* and
*new* versions of the code, talking to the database at the same time.
If I write code that does this:
SELECT foo, bar FROM table
then I do a migration that replaces "bar" with some new table, the new
SQL is:
SELECT table.foo, othertable.bar FROM table JOIN othertable ON
table.id == othertable.foo_id
Those two SQL statements are incompatible. The "new" version of the
code must expect and maintain the old "bar" column for the benefit of
the "old" version of the code still reading and writing to it. To me,
this seems to contradict your suggestion "don't delete columns, ignore
them". We can't ignore "bar" above.
Following these commandments, one can run schema changes at any time. A
new schema should be completely ignorable by older code, because their
columns keep working, and no new requirements are introduced. New code
can deal with defaulted new columns gracefully.
You need to specify how new code deals with the above two totally
different SQL statements "gracefully", except that it has to accommodate
for both versions of the schema at the same time. This may be
"graceful" in operator land but in developer land, there is no easy
solution for this. Unless there is, and nobody has shown it to me yet:
I don't think it's all that ambitious to think we can just use tried and
tested schema evolution techniques that work for everyone else.
People have been asking me for over a year how to do this, and I have no
easy answer, I'm glad that you do. I would like to see some examples of
these techniques.
If you can show me the SQL access code that deals with the above change,
that would help a lot.
If the answer is, "oh well just don't do a schema change like that",
then we're basically saying we aren't really changing our schemas
anymore except for totally new features that otherwise aren't accessed
by the older version of the code. That's fine. It's not what people
coming to me are saying, though.
__________________________________________________________________________
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
