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?

Thanks for reading!
OpenStack Development Mailing List (not for usage questions)

Reply via email to