I think we could accept as a general rule that you can change a database migration (rather than adding a new one) so long as the only actual change in behavior is that the migration now works for people who it would've failed for before (i.e. for people who could successfully run the old version of the migration, the new version does not change the behavior in any way).
-- John On Thu, Feb 11, 2010 at 10:49 AM, Martin Bligh <[email protected]> wrote: > cool, thanks. > > On Thu, Feb 11, 2010 at 10:48 AM, James Ren <[email protected]> wrote: > > This migration would have failed if the TKO database name was not 'tko'. > If > > the migration worked previously, then this fix is unnecessary anyways. > > > > On Thu, Feb 11, 2010 at 10:32 AM, Martin Bligh <[email protected]> > wrote: > >> > >> is it safe to change migrations after they've gone out, rather than > >> do a second fix as a separate migration? > >> > >> Would this have failed if someone had tried to run it already? > >> > >> On Thu, Feb 11, 2010 at 10:26 AM, James Ren <[email protected]> > wrote: > >> > Un-hardcode the TKO database name in AUTOTEST_WEB migration 45 > >> > > >> > Signed-off-by: James Ren <[email protected]> > >> > > >> > --- autotest/frontend/migrations/045_test_planner_framework.py > >> > 2010-02-10 20:32:29.000000000 -0800 > >> > +++ autotest/frontend/migrations/045_test_planner_framework.py > >> > 2010-02-10 20:32:29.000000000 -0800 > >> > @@ -79,7 +79,7 @@ > >> > ; > >> > ALTER TABLE `planner_test_runs` ADD CONSTRAINT test_runs_plan_id_fk > >> > FOREIGN KEY (`plan_id`) REFERENCES `planner_plans` (`id`); > >> > ALTER TABLE `planner_test_runs` ADD CONSTRAINT > test_runs_test_job_id_fk > >> > FOREIGN KEY (`test_job_id`) REFERENCES `planner_test_jobs` (`id`); > >> > -ALTER TABLE `planner_test_runs` ADD CONSTRAINT > test_runs_tko_test_id_fk > >> > FOREIGN KEY (`tko_test_id`) REFERENCES `tko`.`tko_tests` (`test_idx`); > >> > +ALTER TABLE `planner_test_runs` ADD CONSTRAINT > test_runs_tko_test_id_fk > >> > FOREIGN KEY (`tko_test_id`) REFERENCES `%(tko_db_name)s`.`tko_tests` > >> > (`test_idx`); > >> > > >> > > >> > CREATE TABLE `planner_data_types` ( > >> > @@ -178,7 +178,7 @@ > >> > ) > >> > ; > >> > ALTER TABLE `planner_autoprocess_labels` ADD CONSTRAINT > >> > autoprocess_labels_autoprocess_id_fk FOREIGN KEY (`autoprocess_id`) > >> > REFERENCES `planner_autoprocess` (`id`); > >> > -ALTER TABLE `planner_autoprocess_labels` ADD CONSTRAINT > >> > autoprocess_labels_testlabel_id_fk FOREIGN KEY (`testlabel_id`) > REFERENCES > >> > `tko`.`tko_test_labels` (`id`); > >> > +ALTER TABLE `planner_autoprocess_labels` ADD CONSTRAINT > >> > autoprocess_labels_testlabel_id_fk FOREIGN KEY (`testlabel_id`) > REFERENCES > >> > `%(tko_db_name)s`.`tko_test_labels` (`id`); > >> > > >> > > >> > CREATE TABLE `planner_autoprocess_keyvals` ( > >> > @@ -252,4 +252,4 @@ > >> > raise Exception('You must update the TKO database to at least > >> > version ' > >> > '31 before applying AUTOTEST_WEB migration > 45') > >> > > >> > - manager.execute_script(UP_SQL) > >> > + manager.execute_script(UP_SQL % > >> > dict(tko_db_name=tko_manager.get_db_name())) > >> > _______________________________________________ > >> > Autotest mailing list > >> > [email protected] > >> > http://test.kernel.org/cgi-bin/mailman/listinfo/autotest > >> > > > > > > _______________________________________________ > Autotest mailing list > [email protected] > http://test.kernel.org/cgi-bin/mailman/listinfo/autotest >
_______________________________________________ Autotest mailing list [email protected] http://test.kernel.org/cgi-bin/mailman/listinfo/autotest
