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

resources/sql/autopatches/20180828.phriction.06.c.documentid.php

@@ -0,0 +1,20 @@
+<?php
+
+// See T13193. We're about to drop the "documentID" column, which is part of
+// a UNIQUE KEY. In MariaDB, we must first drop the "documentID" key or we get
+// into deep trouble.
+
+// There's no "IF EXISTS" modifier for "ALTER TABLE" so run this as a PHP patch
+// instead of an SQL patch.
+
+$table = new PhrictionContent();
+$conn = $table->establishConnection('w');
+
+try {
+  queryfx(
+    $conn,
+    'ALTER TABLE %T DROP KEY documentID',
+    $table->getTableName());
+} catch (AphrontQueryException $ex) {
+  // Ignore.
+}

resources/sql/autopatches/20180828.phriction.07.documentkey.sql

@@ -0,0 +1,2 @@
+ALTER TABLE {$NAMESPACE}_phriction.phriction_content
+  ADD UNIQUE KEY `key_version` (documentPHID, version);

src/applications/phriction/storage/PhrictionContent.php

@@ -34,7 +34,7 @@ final class PhrictionContent
         'description' => 'text',
       ),
       self::CONFIG_KEY_SCHEMA => array(
-        'documentID' => array(
+        'key_version' => array(
           'columns' => array('documentPHID', 'version'),
           'unique' => true,
         ),