> So, I see your point here, but my concern here is that if we *modify* an > existing schema migration that has already been tested to properly apply > a schema change for MySQL/InnoDB and PostgreSQL with code that is > specific to NDB, we introduce the potential for bugs where users report > that the same migration works sometimes but fails other times.
This ^. The same goes for really any sort of conditional in a migration where you could end up with different schema. I know that is Mike's point (to not have that happen) but I think the difficulty is proving and guaranteeing (now and going forward) that they're identical. Modifying a migration in the past is like a late-breaking conditional. > I would much prefer to *add* a brand new schema migration that handles > conversion of the entire InnoDB schema at a certain point to an > NDB-compatible one *after* that point. That way, we isolate the NDB > changes to one specific schema migration -- and can point users to that > one specific migration in case bugs arise. This is the reason that every > release we add a number of "placeholder" schema migration numbered files > to handle situations such as these. Yes. --Dan __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
