Version 3.105.1

milux

@davidschilling
Scheint ein bisschen kaputt zu sein, das Update.
Unser ChurchTools ist seit heute Nacht offline, und folgendes wird vor dem HTML ausgegeben:

SQLSTATE[42S01]: Base table or view already exists: 1050 Table 'cc_subscription' already exists
Gesamtes SQL: 
                CREATE TABLE `cc_subscription` (
                `person_id` INT NOT NULL,
                `subject` VARCHAR(100) NOT NULL,
                `subject_identifier` VARCHAR(255) NOT NULL,
                `options` JSON,
                `created_date` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
                `created_pid` int NOT NULL,
                `modified_date` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
                `modified_pid` int NOT NULL,
                PRIMARY KEY (`person_id`, `subject`, `subject_identifier`)
                ) ENGINE=InnoDBSQLSTATE[HY000]: General error: 1005 Can't create table `churchtools`.`cc_subscription` (errno: 121 "Duplicate key on write or update")
Gesamtes SQL: ALTER TABLE cc_subscription
            ADD CONSTRAINT cc_subscription_person_id_cdb_person_id
            FOREIGN KEY (person_id)
            REFERENCES cdb_person (id) ON DELETE CASCADESQLSTATE[42S01]: Base table or view already exists: 1050 Table 'cc_html_template' already exists
Gesamtes SQL: CREATE TABLE `cc_html_template` (
                `id` int NOT NULL AUTO_INCREMENT,
                `type` varchar(30) NOT NULL,
                `name` varchar(100) NOT NULL,
                `owner_id` int DEFAULT NULL,
                `is_global` tinyint NOT NULL DEFAULT '0',
                `html_file_id` int DEFAULT NULL,
                `mjml_file_id` int DEFAULT NULL,
                `created_date` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP,
                `created_pid` int NOT NULL,
                `modified_date` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
                `modified_pid` int NOT NULL,
                PRIMARY KEY (`id`),
                KEY `html_template_owner_id_cdb_person_id` (`owner_id`)
                ) ENGINE=InnoDBSQLSTATE[HY000]: General error: 1005 Can't create table `churchtools`.`cc_html_template` (errno: 121 "Duplicate key on write or update")
Gesamtes SQL: ALTER TABLE cc_html_template
            ADD CONSTRAINT cc_html_template_owner_id_cdb_person_id
            FOREIGN KEY (owner_id)
            REFERENCES cdb_person (id) ON DELETE SET NULLSQLSTATE[42S21]: Column already exists: 1060 Duplicate column name 'origin'
Gesamtes SQL: ALTER TABLE cdb_gemeindeperson_gruppe ADD COLUMN origin VARCHAR(20) DEFAULT NULL AFTER waitinglist_positionSQLSTATE[42S21]: Column already exists: 1060 Duplicate column name 'origin'
Gesamtes SQL: ALTER TABLE cdb_gemeindeperson_gruppe_archive ADD COLUMN origin VARCHAR(20) DEFAULT NULL AFTER commentSQLSTATE[42S21]: Column already exists: 1060 Duplicate column name 'origin'
Gesamtes SQL: ALTER TABLE grp_group_membership_history ADD COLUMN origin VARCHAR(20) DEFAULT NULL AFTER comment

Ich dachte, eure DB-Updates seien so geschrieben, dass sie Idempotent laufen?
Sieht gar nicht mal so idempotent aus...

Vorschläge?

davidschilling

@milux
Als erstes würde ich auf die Version davor wechseln und ein Backup vom Vortag einspielen, damit es erstmal wieder läuft.

Ich erinner mich an einen ähnlichen Fall. Überprüfe mal bitte ob bei euch die Tabelle cc_job existiert.

Falls nein kannst du diese anlegen:

CREATE TABLE `cc_job` (
  `identifier` varchar(40) COLLATE utf8mb4_unicode_520_ci NOT NULL,
  `name` varchar(255) COLLATE utf8mb4_unicode_520_ci NOT NULL,
  `args` mediumtext COLLATE utf8mb4_unicode_520_ci NOT NULL,
  `status` varchar(255) COLLATE utf8mb4_unicode_520_ci NOT NULL,
  `domain_type` varchar(255) COLLATE utf8mb4_unicode_520_ci DEFAULT NULL,
  `domain_id` int DEFAULT NULL,
  `created_date` datetime NOT NULL,
  `modified_date` datetime DEFAULT NULL,
  `is_dry_run` int NOT NULL DEFAULT '0',
  PRIMARY KEY (`identifier`),
  KEY `cc_job_ix_domain_id_is_dry_run_status` (`domain_id`,`is_dry_run`,`status`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_520_ci;

Dann muss auch noch die Tabelle cc_job_log angelegt werden:

CREATE TABLE `cc_job_log` (
  `id` int NOT NULL AUTO_INCREMENT,
  `guid` varchar(100) NOT NULL,
  `log` varchar(512) NOT NULL,
  `created_at` datetime NOT NULL,
  `element_id` int NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;

Wenn die Tabellen nicht existieren kannst du in der churchtools.config den Wert test=true setzen und nach dem Einspielen des Backups das Update erneut ausführen, dann sollte die Fehlermeldung aussagekräftiger werden und du kannst dich mit der Fehlermeldung nochmal melden.

milux

Klar, Backup einspielen ist natürlich immer eine schnelle Lösung, um Dinge wieder ans Laufen zu bekommen.
~~Durch das "kaputtgehen" Nachts wären auch wahrscheinlich null Updates verloren gegangen.~~ Ich war einfach gestern zu gestresst und genervt, weil ich ganz andere Sachen zu tun hatte, dass mir diese offensichtliche Lösung nicht in den Sinn kam.
Nachtrag: Wir würden leider einen ganzen Tag Daten verlieren, u.a. diverse Vorbereitungen für den Gottesdienst. Das Backup läuft erst nach 3:00, das Update leider schon 2:00...

Die beiden Tabellen existieren, daran liegt es sicher nicht. Die Fehlermeldungen stehen auch in keinerlei offensichtlichen Zusammenhang mit einer dieser Tabellen.

Da ich das kaputte CT jetzt noch habe, werde ich erstmal das Debugging gem. deines Vorschlags aktivieren, vielleicht bekomme ich ja dann endlich einen verwertbaren Hinweis, bei welchem Schritt es wirklich hängt.

milux

@milux Das hier ist der neue Info-Schnipsel:
SQLSTATE[42000]: Syntax error or access violation: 1071 Specified key was too long; max key length is 1000 bytes
Leider nicht so hilfreich, wie ich gehofft hatte...

milux

@milux Ich habe basierend auf einem "educated guess" folgende Zeile auskommentiert:
addIndex('cc_job', ['domain_id', 'is_dry_run', 'status']);

Voilà: CT updated korrekt und läuft wieder.

Jetzt bin ich aber noch verwirrter als zuvor. Zwei Fragen:

Was ist das für ein komischer Index? Domain-ID und Status verstehe ich ja, aber warum nimmt man den Dry-Run-Status mit?
Ich kann jetzt nur spekulieren, aber scheinbar kommt die Überschreitung des 1000er-Limits durch 255 (varchar) * 4 (mb4-Kodierung) zustande. Wieso ist das nur bei uns explodiert und nicht bei euch? Habt ihr die Limits verändert? Oder hat die DB, wie sie mit Plesk angelegt wird, ungewöhnlich niedrige Werte?
Und warum kann ~~die Domain-ID~~ der Status eigentlich 255 Zeichen lang sein? Haben diese IDs nicht eine wesentlich kleinere, fixe Länge?
Fragen über Fragen...

davidschilling

@milux Schön, dass es wieder läuft. Ich habe gerade nochmal nachgeschaut und die maximale key Size von Mariadb ist seit 10.3 und bei MySQL seit 5.7 3072. Das sollte deutlich über dem Wert sein der bei euch das Limit ausgelöst hat.
Warum das bei euch so ist weiß ich nicht. Welche Version nutzt ihr denn?

milux

@davidschilling Das Problem war die alte Storage Engine, i.e. MyISAM.
Gefixt mit ALTER TABLE cc_job ENGINE = InnoDB;.
In den alten Zeiten von ChurchTools scheinen einige Tabellen wohl damit angelegt worden zu sein, dann könnte ich euch die Schuld dafür in die Schuhe schieben, dass ihr das bei der Migration übersehen habt.
Vielleicht ist es aber auch bei irgendeiner Migration von uns passiert, oder bei einem Restore aus einem Backup. Schwierig, das jetzt noch herauszufinden...

milux

@davidschilling Danke jedenfalls, dass du sogar Sonntag supportest, wenn's brennt.

Ihr lasst auch wirklich keine Möglichkeit aus, uns dazu zu ~~zwingen~~ ermuntern, möglichst bald unter die Flügel eures Cloud-Angebots zu wechseln.

Simon2

@davidschilling
Ich bedauere etwas, dass es der UND-Filterfehler bei automatischen Gruppenmitgliedschaften nicht ins Update geschafft hat.
Wäre der erste (und bislang einzige) Anwendungsfall für dieses tolle Feature bei uns gewesen und für unsere Karnevalsfreizeit sehr hilfreich...

Nungut, ich hoffe, es bleibt auf der Liste und kommt bald.

Gruß

Simon

Tobias Lachmann

@milux Ich wünschte, ich würde verstehen, was genau hier in eurer Unterhaltung abging … komme aber nicht ganz dahinter.