Open Stack

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.