On 3/9/2014 9:05 PM, ChangBo Guo wrote:
2014-03-10 4:47 GMT+08:00 Jay Pipes <jaypi...@gmail.com <mailto:jaypi...@gmail.com>>: > 3. This would make the instances and shadow_instances tables have > different schemas, i.e. instances.uuid would be nullable=False in > instances but nullable=True in shadow_instances. Maybe this doesn't matter. No, I don't think this matters much, to be honest. I'm not entirely sure what the long-term purpose of the shadow tables are in Nova -- perhaps someone could clue me in to whether the plan is to keep them around? As I know the tables shadow_* are used by command ' nova-manage db archive_deleted_rows' , which moves records with "deleted=True" to table shadow_* . That means these tables are used by other process, So, I think we need other tables to store the old records in your migration .
So you mean move records where instances.uuid == None to shadow_instances? That's not going to work though if we make the uuid column non-nullable on both instances and shadow_instances, unless you generate a random UUID for the shadow_instances table records that get moved, which is just another hack - and that would break moving them back on downgrade since you wouldn't know which records to move back, i.e. since you wouldn't be able to query shadow_instances for records where instances.uuid == None.
Other thoughts? If you did really want to back these records up, I think it would have to be a different backup table rather than shadow_instances since I think we want to keep the schema the same between instances and shadow_instances.
-- ChangBo Guo(gcb) _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-- Thanks, Matt Riedemann _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
