Seit mehreren Jahren läuft bei mir in verschiedenen Projekten bei unterschiedlichen Hostern Borlabs Cookie. Das gibt es seit mehreren Monaten auch als Version 3.0, bis Ende Januar war es noch Beta. Mittlerweile soll die Betaphase vorbei sein. Ein Update ist nicht unbedingt (gleich) erforderlich, macht aber wohl Sinn, und ist in manchen Fällen mittlerweile auch angeraten.

Also Herz gefasst, und schon mal das eine oder andere Update gemacht. Gestern war dann die Multisite-Installation eines Kunden dran. Altes Borlabs Cookie raus, neues rein, erste Subsite konfiguriert, weiter zur zweiten Subsite gegangen, doch da stand ich dann vor der Fehlermeldung:

Can't create table `dbname`.`prefix_6_borlabs_cookie_cloud_scan_external_resources` (errno: 121 "Duplicate key on write or update")
Can't create table `dbname`.`prefix_6_borlabs_cookie_content_blocker_locations` (errno: 121 "Duplicate key on write or update")

Die schickte ich gleich mal weiter an den Support, mit Infos über Serverumgebung, Datenbank und dass es sich um eine Multisite-Installation handle. Signifikant war, dass auf der Haupt- und einer Subsite alles OK zu sein schien. Erst die zweite Subsite meldete das Problem.

Der Support meinte dann, ich solle alles nochmal deinstallieren und wieder von vorne anfangen. Das tat ich dann auch, löschte vorher sogar sämtliche borlabs-Tabellen aus der Datenbank. Der Fehler kam wieder. Erneut entfernte ich die Tabellen. Dachte, ich wäre ganz schlau, wenn ich einfach auf jeder Subsite Borlabs einzeln aktiviere, am Ende dann alle wieder deaktiviere, und Borlabs netzwerkaktiv schalte. Gleicher Fehler. Die erste Aktivierung war (schien) erfolgreich (egal auf welcher Subsite), die nächste nicht mehr.

Nächster Test: Lokalhost, die Testumgebung für das Projekt. Unterschied: IIS und mySQL-Server (nicht wie im Wirkbetrieb Apache und mariaDB). Hier gab es keine Probleme. Es (be)traf also nur mariaDB.

Nochmal den Support kontaktiert, diesmal mit mehr Details. Es stellte sich heraus, dass mein Tabellenpräfix für die elendiglangen Keys in den neuen Borlabs-Tabellen zu viele Zeichen hatte. Dadurch wurde bei der Installation aus (x steht für die jeweilige Site-ID):

prefix_x_borlabs_cookie_cloud_scan_external_resources_cloud_scan_id

fk_pfrx__cld_scn_xtrnl_rsrcs_cloud_scan_id

Das wiederholte sich bei jeder Subsite, wodurch das Anlegen der Tabellen aufgrund doppelter Constraints abgebrochen wurde (Duplicate Key Error).

Das Problem entsteht durch die Beschränkung der maximalen Länge von Schlüsseln in mariaDB-Datenbanken. mariaDB hat eine maximale Indexlänge von 767 Bytes (für InnoDB-Tabellen und utf8mb4-Codierung). Wenn das benutzerdefinierte Präfix zu lang ist, kann die Gesamtlänge des Schlüsselnamens zusammen mit dem Tabellennamen und den Zusätzen den zulässigen Grenzwert überschreiten.

Ein Ansatz wäre die Erhöhung der maximalen Schlüssellänge in der mariaDB-Konfiguration, was allerdings nicht immer empfehlenswert ist, da es Seiteneffekte haben kann.

Entwickler sollten bedenken, dass lange Präfixe oder Schlüsselnamen Kompatibilitätsprobleme verursachen können. Es ist ratsam, möglichst kurze, aber eindeutige Namen zu verwenden.

Ein Konfigurationsschritt, der die Länge des Präfixes überprüft und gegebenenfalls warnt oder anpasst, wäre hilfreich.

Mit einem ganz kurzen Prefix (wie es bei einschlägigen Plugins oder auch „Secure Installations“ nicht vorgesehen wird, die sind eher noch länger als meine) wie z.B. xb_ funktionierte die Installation. Warum ich nach über 15 Jahren Custom Präfix erstmalig darüber nachdenken muss, sie kürzer als 6-8 Zeichen zu machen, dafür fehlt mir ein wenig das Verständnis. Als Entwickler sollte man auch mit längeren Zeichenfolgen rechnen (z.B. so viele, wie Plugins zum Ändern des Präfixes üblicherweise vorschlagen), und seine Keys entsprechend benennen.