-- 985_tracks_storage_backend.sql -- v1.0.8 Phase 0 (MinIO upload migration) — prepare tracks schema for -- multi-backend storage (local FS vs S3/MinIO). Schema-only change; Phase 1 -- will wire TrackService.UploadTrack() to actually route writes via the -- storage_backend column. -- -- Context: FUNCTIONAL_AUDIT §4 item 2 flagged "stockage local disque only" -- as a multi-pod prod blocker. The S3 client exists but is never called on -- the upload path. This migration makes it possible to gradually migrate -- uploads without a big-bang switchover. -- -- Columns added: -- storage_backend — VARCHAR(16) NOT NULL DEFAULT 'local' -- Which storage impl wrote this track. 'local' = file_path points at -- veza-backend-api/uploads/tracks/... . 's3' = storage_key holds the -- S3 object key inside config.S3Bucket. Check constraint limits values. -- -- storage_key — VARCHAR(512) NULL -- When storage_backend='s3', this is the S3 object key (e.g. -- "tracks//."). NULL when storage_backend='local' -- (file_path carries the info in that case — kept for back-compat). -- -- Index: -- idx_tracks_storage_backend_s3 — partial index on s3-backed rows only. -- Useful for the migration script (Phase 3) which sweeps local→s3 and -- for monitoring queries (what % of tracks already migrated). ALTER TABLE public.tracks ADD COLUMN storage_backend VARCHAR(16) NOT NULL DEFAULT 'local' CHECK (storage_backend IN ('local', 's3')), ADD COLUMN storage_key VARCHAR(512); -- Partial index: only indexes s3-backed rows (majority stay 'local' during -- migration, so full index would be wasteful). CREATE INDEX idx_tracks_storage_backend_s3 ON public.tracks(storage_backend) WHERE storage_backend = 's3'; COMMENT ON COLUMN public.tracks.storage_backend IS 'Storage impl that owns the file: local (disk) or s3 (MinIO/S3). v1.0.8 multi-backend prep.'; COMMENT ON COLUMN public.tracks.storage_key IS 'S3 object key when storage_backend=s3. NULL when storage_backend=local (file_path carries the info).';