From c146f7e8772328bf5e62a13b4f78d237e533d0d8 Mon Sep 17 00:00:00 2001 From: ConnorYoh <40631091+ConnorYoh@users.noreply.github.com> Date: Tue, 11 Aug 2026 13:53:56 +0100 Subject: [PATCH] chore(saas): drop the last dead Flyway migration (#7433) Removes `app/saas/src/main/resources/db/migration/saas/V33__api_keys.sql`, the only file left in that tree. ## Flyway does not run There is no Flyway dependency in any `build.gradle` and no Flyway configuration in any properties file. Nothing has executed these for some time, so `V33` was never applied by anything. SaaS schema has exactly two writers today: 1. Supabase CLI migrations in the `Stirling-PDF-SaaS` repo, applied by that repo's PR CI 2. Hibernate `ddl-auto=update` in the app, which only ever adds ## Why delete rather than leave it A directory of plausible-looking migrations is a trap. The next person to make a schema change adds a `V34`, assumes it will run, and it silently does not. I nearly did exactly that while working on [#7414](https://github.com/Stirling-Tools/Stirling-PDF/pull/7414) before checking whether Flyway was actually wired. ## Nothing is lost Both tables it declared, `api_keys` and `api_key_daily_usage`, have JPA entities (`ApiKey`, `ApiKeyDailyUsage`), so `ddl-auto` creates them. That is already how they exist on every deployment that has them, since Flyway was not the thing creating them. ## Checks No references anywhere: nothing in code, config, gradle or docs mentions `db/migration`, `flyway` or `V33`. Two code comments mention Flyway historically, explaining why a column looks the way it does; those are accurate history and are left alone. `:saas:compileJava` and `:saas:processResources` green after the removal. --- .../db/migration/saas/V33__api_keys.sql | 24 ------------------- 1 file changed, 24 deletions(-) delete mode 100644 app/saas/src/main/resources/db/migration/saas/V33__api_keys.sql diff --git a/app/saas/src/main/resources/db/migration/saas/V33__api_keys.sql b/app/saas/src/main/resources/db/migration/saas/V33__api_keys.sql deleted file mode 100644 index abced067e6..0000000000 --- a/app/saas/src/main/resources/db/migration/saas/V33__api_keys.sql +++ /dev/null @@ -1,24 +0,0 @@ --- Named, multi-key personal API keys, plus per-key daily usage. --- Idempotent: Hibernate ddl-auto=update may already have created these on some deployments. - -CREATE TABLE IF NOT EXISTS api_keys ( - id BIGSERIAL PRIMARY KEY, - name VARCHAR(100) NOT NULL, - key_hash VARCHAR(64) NOT NULL, - prefix VARCHAR(32) NOT NULL, - owner_user_id BIGINT NOT NULL, - enabled BOOLEAN NOT NULL DEFAULT TRUE, - created_at TIMESTAMPTZ NOT NULL, - last_used_at TIMESTAMPTZ, - revoked_at TIMESTAMPTZ -); - -CREATE UNIQUE INDEX IF NOT EXISTS idx_api_key_hash ON api_keys (key_hash); -CREATE INDEX IF NOT EXISTS idx_api_key_owner ON api_keys (owner_user_id); - -CREATE TABLE IF NOT EXISTS api_key_daily_usage ( - api_key_id BIGINT NOT NULL, - epoch_day BIGINT NOT NULL, - count BIGINT NOT NULL DEFAULT 0, - PRIMARY KEY (api_key_id, epoch_day) -);