> I haven't looked at what Keystone is doing, but to the degree they are > using triggers, those triggers would only impact new data operations as > they continue to run into the schema that is straddling between two > versions (e.g. old column/table still exists, data should be synced to > new column/table). If they are actually running a stored procedure to > migrate existing data (which would be surprising to me...) then I'd > assume that invokes just like any other "ALTER TABLE" instruction in > their migrations. If those operations themselves rely on the triggers, > that's fine.
I haven't looked closely either, but I thought the point _was_ to transform data. If they are, and you run through a bunch of migrations where you end at a spot that expects that data was migrated while running at step 3, triggers dropped at step 7, and then schema compacted at step 11, then just blowing through them could be a problem. It'd work for a greenfield install no problem because there was nothing to migrate, but real people would trip over it. > But a keystone person to chime in would be much better than me just > making stuff up. Yeah, same :) --Dan __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
