CRM-18464 use safe drop foreign key function to resolve upgrade error…

[seamuslee001]

… and also drop Index with same name as foreign key being dropped if it exists
https://issues.civicrm.org/jira/browse/CRM-18464

[totten]

Scheudle

[totten]

Overall, +1 for more guarded schema changes.

[totten]

So I did a test run of 9ef9434 roughly as follows:

cd sites/all/modules/civicrm
git checkout master && git scan up && ./bin/setup.sh -g

civibuild ut dmaster 4.6.11*
mysqldump civi > /tmp/upgrade.orig

git scan am https://github.com/civicrm/civicrm-core/pull/9679 --new
civibuild ut dmaster 4.6.11*
mysqldump civi > /tmp/upgrade.new

colordiff -u /tmp/upgrade.{orig,new}

The schema ends up slightly different -- i.e. the old code has FK_civicrm_action_schedule_mapping_id in the final ouptut, but the new code does not. Is that the intended effect?

CREATE TABLE `civicrm_action_schedule` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  ...
  KEY `FK_civicrm_action_schedule_mapping_id` (`mapping_id`),
  ...

Is that the intended effect? Does this mean the old code was misbehaving?

[seamuslee001]

I think so i have a feeling it may have not 100% but that is strange, I would expect the foreign key to be dropped.

[totten]

jenkins, test this please

[colemanw]

@totten is this ready to merge?

[seamuslee001]

@totten @colemanw I think i have fixed the difference in the code in that i didn't relise KEY was just meaning an index I think this is good to go

[totten]

Confirmed that the new upgrade logic produces the same schema as the old upgrade logic (but with safer code).