-- Nachklang e.V. Calendar module — step 1 of docs/calendar-auth-migration.md. -- Adds the bridging columns that let an event record who created it as an -- *admin* user id (VARCHAR(36)) alongside the legacy calendar users.user_id -- (INT). Apply manually against the CALENDAR_DB database: -- mysql -h -u -p < 001_add_admin_user_bridge.sql -- -- Numbered 001 because this is the first migration this repo owns for the -- calendar schema: the tables themselves predate it and were provided by the -- repo owner (mirrored for dev in docker/init/01-calendar-schema-dev.sql). -- -- Nothing reads these columns yet — step 3 introduces the dual-read. Adding -- them first means the backfill in step 2 has somewhere to write, and this -- migration can be applied to production on its own without any code change. -- -- No foreign key, on purpose. The admin `user` table lives in a *different* -- database (nachklang_admin) behind a different connection pool, and a -- cross-schema FK would tie the two schemas' lifecycles together: you could no -- longer dump, restore or move one without the other. The reference is -- enforced in application code, which is also where the legacy/new fallback -- lives. -- -- The collation is pinned to the admin database's (utf8mb4_unicode_ci) rather -- than inherited from the calendar tables' utf8mb4_general_ci. These columns -- hold ids that only ever compare against nachklang_admin.user.id, and a -- mismatched collation makes any such comparison fail at runtime with -- "Illegal mix of collations" instead of at review time. ALTER TABLE `events` ADD COLUMN `created_by_user_id` VARCHAR(36) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NULL DEFAULT NULL AFTER `created_by_id`, ADD KEY `events_created_by_user_idx` (`created_by_user_id`); ALTER TABLE `event_versions` ADD COLUMN `version_created_by_user_id` VARCHAR(36) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NULL DEFAULT NULL AFTER `version_created_by_id`, ADD KEY `event_versions_created_by_user_idx` (`version_created_by_user_id`);