Broken update hook added in v1.0.10

FYI, if I try updating directly from 1.0.9 to 1.0.11 the error above still occurs when running update hooks, except the error message is slightly different with "entity_uuid" replaced with "integration_link_id"

OK, this is very odd. When I inspect the `acquia_dam_integration_link_tracking` table in our live site running 1.0.9 I already see "integration_link_id" marked as PRI for the key. And yet Drupal status page is still complaining that this table doesn't have a primary key. So now I'm really confused.

But here is the exact error when upgrading from 1.0.9 to 1.0.11 (different then I mentioned above)

> [notice] Update started: acquia_dam_post_update_link_tracking_primary_key
> [error] SQLSTATE[42000]: Syntax error or access violation: 1280 Incorrect index name 'integration_link_id': ALTER TABLE "acquia_dam_integration_link_tracking" ADD PRIMARY KEY ("integration_link_id"); Array
> (
> )

I think I see part of the problem here:

In 1.0.10 this post_update hook was added: `acquia_dam_post_update_link_tracking_primary_key` and is mistakenly set the primary key as `entity_uuid` which isn't unique.

Then in 1.0.11, the above update hook code was fixed to change the key to `integration_link_id` and a NEW post_update hook was added: `acquia_dam_post_update_link_tracking_change_primary_key`

But these post_update hooks run in alphabetical order. So when updating from 1.0.9 directly to 1.0.11, BOTH hooks run, with the new update hook added in 1.0.11 running FIRST and then the old "fixed" hook from 1.0.10 tries to run and gives the error above.

Still not clear why it throws an error and why the status page still indicates there is no primary key on this table.

OK, sorry for all the confusion above as I tried to debug this, but I found the cause and solution.

The problem is that there is already an index on `acquia_dam_integration_link_tracking` with a name of `integration_link_id`. And you can't add this as a Primary key when this index already exists. The error message "Incorrect index name" is very misleading.

In the `acquia_dam_post_update_link_tracking_primary_key` hook, when you detect that there isn't any primary key, before trying to add the primary key you first need to check if there is an index named `integration_link_id` already, and drop that index first, and THEN create the primary index.

So the correct code for that update hook would be:

function acquia_dam_post_update_link_tracking_primary_key(&$sandbox) {
  $schema = Database::getConnection()->schema();
  if (!$schema->indexExists('acquia_dam_integration_link_tracking', 'PRIMARY')) {
    if ($schema->indexExists('acquia_dam_integration_link_tracking', 'integration_link_id')) {
      $schema->dropIndex('acquia_dam_integration_link_tracking', 'integration_link_id');
    }
    $schema->addPrimaryKey('acquia_dam_integration_link_tracking', ['integration_link_id']);
  }
}

Of course, now it's a mess because that update hook already exists and potentially could have already run on an existing site. So I'm not sure simply changing this hook will work for all users. However, it worked for me when upgrading from 1.0.9 to 1.0.11

So I'm adding a patch here just so I can apply it to my local (and anyone else upgrading from versions prior to 1.0.10 where this problem first occured). But the actual fix for your next release might need to be different.

ahh yes that is correct. Guessing people won't really run into that now, but its good to have just in case. Merged!

Automatically closed - issue fixed for 2 weeks with no activity.