Take the array key into account when checking whether an unnamed KEY matches in Datab...

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

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 3ee2a2b7b60d95dd93c6431d128000722a8e15ea..7e555f88b3a88f0c815234d8dc3de2edab07d608 100644 (file)
--- 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();