On 9/4/13 6:47 AM, Michael Still wrote:
On Wed, Sep 4, 2013 at 1:54 AM, Vishvananda Ishaya
<vishvana...@gmail.com> wrote:
+1 I think we should be reconstructing data where we can, but keeping track of
deleted data in a backup table so that we can restore it on a downgrade seems
like overkill.
I guess it comes down to use case... Do we honestly expect admins to
regret and upgrade and downgrade instead of just restoring from
backup? If so, then we need to have backup tables for the cases where
we can't reconstruct the data (i.e. it was provided by users and
therefore not something we can calculate).
So assuming we don't keep the data in some kind of backup state is there
a way we should be documenting which migrations are backwards
incompatible? Perhaps there should be different classifications for
data-backwards incompatible and schema incompatibilities.
Having given it some more thought, I think I would like to see
migrations keep backups of obsolete data. I don't think it is
unforeseeable that an administrator would upgrade a test instance (or
less likely, a production) by accident or not realising their backups
are corrupted, outdated or invalid. Being able to roll back from this
point could be quite useful. I think potentially more useful than that
though is that if somebody ever needs to go back and look at some data
that would otherwise be lost it is still in the backup table.
As such I think it might be good to see all migrations be downgradable
through the use of backup tables where necessary. To couple this I think
it would be good to have a standard for backup table naming and maybe
schema (similar to shadow tables) as well as an official list of backup
tables in the documentation stating which migration they were introduced
and how to expire them.
In regards to the backup schema, it could be exactly the same as the
table being backed up (my preference) or the backup schema could contain
just the lost columns/changes.
In regards to the name, I quite like "backup_table-name_migration_214".
The backup table name could also contain a description of what is backed
up (for example, 'uuid_column').
In terms of expiry they could be dropped after a certain release/version
or left to the administrator to clear out similar to shadow tables.
Thoughts?
Cheers,
Josh
--
Rackspace Australia
Michael
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
