mirror of
https://github.com/Stirling-Tools/Stirling-PDF.git
synced 2026-09-03 05:10:16 +03:00
ConnorYoh
c146f7e877
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.