From bba6c47145d44928b22be80b057cfefd1b386f8f Mon Sep 17 00:00:00 2001 From: =?utf8?q?Tim=20D=C3=BCsterhus?= Date: Tue, 21 Sep 2021 16:31:17 +0200 Subject: [PATCH] Take the array key into account when checking whether an unnamed KEY matches in DatabaseTableChangeProcessor The reproducer effectively matches d7f721d6f920d66f75102723b504d89e57a8c9ff, except that the KEY is unnamed. Previously the update would silently fail to do anything. Now the update fails loudly, because it attempts to create another index with an existing name. This is no different behavior compared to an INDEX collision of two unnamed indices `(a, b)`, `(a, c)`. The developer will be clearly alerted of this issue and can take appropriate measures to avoid it, e.g. by using explicit names. see #4434 --- .../database/table/DatabaseTableChangeProcessor.class.php | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/wcfsetup/install/files/lib/system/database/table/DatabaseTableChangeProcessor.class.php b/wcfsetup/install/files/lib/system/database/table/DatabaseTableChangeProcessor.class.php index 3ee2a2b7b6..7e555f88b3 100644 --- a/wcfsetup/install/files/lib/system/database/table/DatabaseTableChangeProcessor.class.php +++ b/wcfsetup/install/files/lib/system/database/table/DatabaseTableChangeProcessor.class.php @@ -821,7 +821,7 @@ class DatabaseTableChangeProcessor protected function diffIndices(DatabaseTableIndex $oldIndex, DatabaseTableIndex $newIndex) { if ($newIndex->hasGeneratedName()) { - return !empty(\array_diff($oldIndex->getData(), $newIndex->getData())); + return !empty(\array_diff_assoc($oldIndex->getData(), $newIndex->getData())); } return $oldIndex->getName() !== $newIndex->getName(); -- 2.20.1