Open Stack

On 01/29/2015 03:11 PM, Mike Bayer wrote:
>
> 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



Except that is it is code we need to maintain and support.  I think we 
are making more work for ourselves than the value these scripts provide 
justify.
>   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.
>
>
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev