[SAP] drop existing SAP constraint

[hemna]

This patch updates the 141 DB version upgrade to first drop the existing quota_usages table constraint on quota_usages_project_id_key, which happens to be UNIQUE (project_id, resource, deleted).

141 by default adds a unique constraint on the same key as ALTER TABLE quota_usages ADD CONSTRAINT quota_usages_project_id_key UNIQUE (project_id, resource, race_preventer)

Saw this while doing an upgrade on qa-de-2 from train -> wallaby. This didn't happen on qa-de-3, but looking at
the DB tables in production, they will all have this same problem.

qa-de-1

| quota_usages | CREATE TABLE `quota_usages` (\n  `created_at` datetime DEFAULT NULL,\n  `updated_at` datetime DEFAULT NULL,\n  `deleted_at` datetime DEFAULT NULL,\n  `deleted` tinyint(1) DEFAULT NULL,\n  `id` int(11) NOT NULL AUTO_INCREMENT,\n  `project_id` varchar(255) DEFAULT NULL,\n  `resource` varchar(300) DEFAULT NULL,\n  `in_use` int(11) NOT NULL,\n  `reserved` int(11) NOT NULL,\n  `until_refresh` int(11) DEFAULT NULL,\n  PRIMARY KEY (`id`),\n  UNIQUE KEY `quota_usages_project_id_key` (`project_id`,`resource`,`deleted`),\n  KEY `ix_quota_usages_project_id` (`project_id`),\n  KEY `quota_usage_project_resource_idx` (`project_id`,`resource`),\n  CONSTRAINT `CONSTRAINT_1` CHECK (`deleted` in (0,1))\n) ENGINE=InnoDB AUTO_INCREMENT=24225 DEFAULT CHARSET=utf8 |

ap-ae-1

| quota_usages | CREATE TABLE `quota_usages` (\n  `created_at` datetime DEFAULT NULL,\n  `updated_at` datetime DEFAULT NULL,\n  `deleted_at` datetime DEFAULT NULL,\n  `deleted` tinyint(1) DEFAULT NULL,\n  `id` int(11) NOT NULL AUTO_INCREMENT,\n  `project_id` varchar(255) DEFAULT NULL,\n  `resource` varchar(300) DEFAULT NULL,\n  `in_use` int(11) NOT NULL,\n  `reserved` int(11) NOT NULL,\n  `until_refresh` int(11) DEFAULT NULL,\n  PRIMARY KEY (`id`),\n  UNIQUE KEY `quota_usages_project_id_key` (`project_id`,`resource`,`deleted`),\n  KEY `ix_quota_usages_project_id` (`project_id`),\n  KEY `quota_usage_project_resource_idx` (`project_id`,`resource`),\n  CONSTRAINT `CONSTRAINT_1` CHECK (`deleted` in (0,1))\n) ENGINE=InnoDB AUTO_INCREMENT=372 DEFAULT CHARSET=utf8 |

qa-de-3, which is already running wallaby-m3

| quota_usages | CREATE TABLE `quota_usages` (\n  `created_at` datetime DEFAULT NULL,\n  `updated_at` datetime DEFAULT NULL,\n  `deleted_at` datetime DEFAULT NULL,\n  `deleted` tinyint(1) DEFAULT NULL,\n  `id` int(11) NOT NULL AUTO_INCREMENT,\n  `project_id` varchar(255) DEFAULT NULL,\n  `resource` varchar(300) DEFAULT NULL,\n  `in_use` int(11) NOT NULL,\n  `reserved` int(11) NOT NULL,\n  `until_refresh` int(11) DEFAULT NULL,\n  `race_preventer` tinyint(1) DEFAULT NULL,\n  PRIMARY KEY (`id`),\n  UNIQUE KEY `project_id` (`project_id`,`resource`,`deleted`),\n  UNIQUE KEY `quota_usages_project_id_key` (`project_id`,`resource`,`race_preventer`),\n  KEY `quota_usage_project_resource_idx` (`project_id`,`resource`),\n  KEY `ix_quota_usages_project_id` (`project_id`),\n  CONSTRAINT `CONSTRAINT_1` CHECK (`deleted` in (0,1))\n) ENGINE=InnoDB AUTO_INCREMENT=15 DEFAULT CHARSET=utf8 |

[grandchild]

So this effectively reverts ae2a740 .
Did anything happen since that commit which makes this constraint obsolete and still prevents double quota spending?

[hemna]

That patch was made by us ages ago. Upstream fixed the same issue with a slightly different unique constraint, which is as effective. We should use upstream's fix.

[grandchild]

That sounds reasonable 🙂.