export const id = '20261004-release-name-lookup';
export const name = 'Release-Auflösung: ein Name statt Zeiger/Canary (AppRelease.Backends/Current und OrgReleaseOverride entfallen)';
/**
* Die Auslieferung wird **ein Nachschlagen per Name** — Zeiger und Canary
* entfallen.
*
* ## Was abgelöst wird
*
* Die Migration `20260928-app-release` hat `AppRelease` als **Zeiger** gebaut
* (`Current` markiert die ausgelieferte Zeile) und `OrgReleaseOverride` als
* Canary-Ausnahme für eine einzelne Organisation. `20261003-app-backend-branches`
* hat die Backends aus der Release-Zeile gelöst und in `AppBackendBranch`
* gelegt, `AppRelease.Backends` blieb als Rückfall stehen.
*
* Beides ist jetzt weg — nicht als Optimierung, sondern weil es zwei Quellen für
* dieselbe Frage waren:
*
* | Vorher | Jetzt |
* |---|---|
* | `OrgAppDeployment.Version` → sonst `OrgReleaseOverride` → sonst `AppRelease.Current` | `OrgAppDeployment.Version` → sonst der Name `stable` |
* | Backends: `AppRelease.Backends` als Rückfall | Backends: **nur** `AppBackendBranch` (der gewählte Zweig) |
*
* ## Warum `Current` und Canary ersatzlos entfallen
*
* Der Default ist kein Zustand, sondern ein **Name**: `stable`. Die Subdomain
* ohne eigene Wahl folgt der letzten von CommTool als `stable` getaggten
* Version, und diese Wahl trifft der `X.Y.Z-stable`-Tag — kein `UPDATE` an einer
* Zeile. Damit gibt es keine Reihenfolge von Stufen mehr, in der ein Defekt sich
* verstecken kann: entweder die Zeile `stable` existiert (dann wird ausgeliefert)
* oder nicht (dann 503). Eine org-spezifische Canary-Ausnahme ist mit demselben
* Mechanismus ausdrückbar — sie ist eine `OrgAppDeployment.Version`, und die
* gehört dem Kunden-Admin, nicht CommTool.
*
* ## Warum `AppRelease.Backends` nicht bleiben kann
*
* Ein Rückfall „Release-Backends, wenn der Zweig fehlt" hätte eine **Wahl des
* Admins still überschrieben**: die Organisation hätte einen Zweig gewählt und
* bekäme die URLs der Release-Zeile. Seit `20261003` ist der Zweig die einzige
* Adressierung; die Spalte war seitdem nur noch eine zweite Wahrheit.
*
* ## Idempotenz
*
* `DROP … IF EXISTS` auf Spalten, Index und Tabelle: die Migration darf gegen
* einen Bestand laufen, der eine der Änderungen schon trägt (z.B. eine frische
* Installation, deren `initTables.sql` bereits ohne sie ist). Wie überall in
* diesem Verzeichnis gilt: die Migration ist die Wahrheit für Bestandsdaten,
* `initTables.sql` die Vorlage für frische Installationen.
*
* @see PLAN.md §6.9 — Backends sind ein eigener Vertrag und eine Admin-Wahl
*/
/** Der Zeiger: `(AppKey, Current)` existierte nur für „genau eine Zeile ist die ausgelieferte". */
const DROP_CURRENT_INDEX = 'ALTER TABLE `AppRelease` DROP INDEX IF EXISTS `idx_current`';
const DROP_CURRENT_COLUMN = 'ALTER TABLE `AppRelease` DROP COLUMN IF EXISTS `Current`';
/** Der Rückfall: die Backends kamen aus der Release-Zeile, seit `20261003` gehört der Zweig sie. */
const DROP_BACKENDS_COLUMN = 'ALTER TABLE `AppRelease` DROP COLUMN IF EXISTS `Backends`';
/** Die Canary-Ausnahme einer einzelnen Organisation — ersetzt durch `OrgAppDeployment.Version`. */
const DROP_OVERRIDE_TABLE = 'DROP TABLE IF EXISTS `OrgReleaseOverride`';
export const migrate = async ({ query }) => {
// Reihenfolge: erst der Index, dann die Spalte, auf der er liegt.
await query(DROP_CURRENT_INDEX, []);
await query(DROP_CURRENT_COLUMN, []);
await query(DROP_BACKENDS_COLUMN, []);
await query(DROP_OVERRIDE_TABLE, []);
};