Open Stack

On 01/29/2015 11:06 AM, Morgan Fainberg wrote:
> As a quick preface, today there is the assumption you can upgrade and downgrade your SQL Schema. For the most part we do our best to test all of this in our unit tests (do upgrades and downgrades land us in the same schema). What isn’t clearly addressed is that the concept of downgrade might be inherently flawed, especially when you’re talking about the data associated with the migration. The concept that there is a utility that can (and in many cases willfully) cause permanent, and in some cases irrevocable, data loss from a simple command line interface sounds crazy when I try and explain it to someone.
> 
> The more I work with the data stored in SQL, and the more I think we should really recommend the tried-and-true best practices when trying to revert from a migration: Restore your DB to a known good state.
> 
> * If a migration fails in some spectacular way (that was not handled gracefully) is it possible to use the downgrade mechanic to “fix” it? More importantly, would you trust the data after that downgrade?
> * Once an upgrade has happened and new code is run (potentially making use of the new data structures), is it really safe to downgrade and lose that data without stepping back to a known consistent state?
> 
> The other side of this coin is that it prevents us from collapsing data types in the stable store without hints to reverse the migration.
> 
> I get the feeling that the reason we provide downward migrations today is because we have in the past. Due to the existence of these downward migrations the expectation is that they will work, and so we’re in a weird feedback-loop.
> 
> I’d like to propose we stop setting the expectation that a downwards migration is a “good idea” or even something we should really support. Offering upwards-only migrations would also simplify the migrations in general. This downward migration path is also somewhat broken by the migration collapses performed in a number of projects (to limit the number of migrations that need to be updated when we change a key component such as oslo.db or SQL-Alchemy Migrate to Alembic).
> 
> Are downward migrations really a good idea for us to support? Is this downward migration path a sane expectation? In the real world, would any one really trust the data after migrating downwards?

I do not think downward migrations are a good idea. I think they are a
spectacularly bad idea that is essentially designed to get users into a
state where they are massively broken.

Operators should fail forward or restore from backup. Giving them
downgrade scripts will imply that they work, which they probably will
not once actual data is involved.

Monty