@recaptime-dev's working patches + fork for Phorge, a community fork of Phabricator. (Upstream dev and stable branches are at upstream/main and upstream/stable respectively.)
hq.recaptime.dev/wiki/Phorge
phorge
phabricator
Work around an issue in MariaDB where dropping a column from a UNIQUE KEY fails
Summary:
See T13193. See T13077. If we drop a column which is part of a UNIQUE KEY, MariaDB raises an error.
This is probably a bad idea on our side anyway, but in this case it wasn't an obviously bad idea.
To get around this:
- Drop the unique key, if it exists, before dropping the column.
- Explicitly add the new unique key afterward.
Test Plan: Ran `bin/storage upgrade` locally without issue, but I'm on MySQL. Will follow up on T13193.
Reviewers: amckinley
Subscribers: PHID-OPKG-gm6ozazyms6q6i22gyam
Differential Revision: https://secure.phabricator.com/D19624
+23
-1
+20
resources/sql/autopatches/20180828.phriction.06.c.documentid.php
+20
resources/sql/autopatches/20180828.phriction.06.c.documentid.php
···
1
+
<?php
2
+
3
+
// See T13193. We're about to drop the "documentID" column, which is part of
4
+
// a UNIQUE KEY. In MariaDB, we must first drop the "documentID" key or we get
5
+
// into deep trouble.
6
+
7
+
// There's no "IF EXISTS" modifier for "ALTER TABLE" so run this as a PHP patch
8
+
// instead of an SQL patch.
9
+
10
+
$table = new PhrictionContent();
11
+
$conn = $table->establishConnection('w');
12
+
13
+
try {
14
+
queryfx(
15
+
$conn,
16
+
'ALTER TABLE %T DROP KEY documentID',
17
+
$table->getTableName());
18
+
} catch (AphrontQueryException $ex) {
19
+
// Ignore.
20
+
}
+2
resources/sql/autopatches/20180828.phriction.07.documentkey.sql
+2
resources/sql/autopatches/20180828.phriction.07.documentkey.sql