Open Stack

Morgan Fainberg <morgan.fainberg at gmail.com> wrote:

> 
> 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?

It’s a good idea for a migration script to include a rudimentary downgrade operation to complement the upgrade operation, if feasible.  The purpose of this downgrade is from a practical standpoint helpful when locally testing a specific, typically small series of migrations.

A downgrade however typically only applies to schema objects, and not so much data.   It is often impossible to provide downgrades of data changes as it is likely that a data upgrade operation was destructive of some data.  Therefore, when dealing with a full series of real world migrations that include data migrations within them, downgrades are typically impossible.   I’m getting the impression that our migration scripts have data migrations galore in them.   

So I am +1 on establishing a policy that the deployer of the application would not have access to any “downgrade” migrations, and -1 on removing “downgrade” entirely from individual migrations.   Specific migration scripts may return NotImplemented for their downgrade if its really not feasible, but for things like table and column changes where autogenerate has already rendered the downgrade, it’s handy to keep at least the smaller ones working.