fix(db): rename schema v1_owners_club → v10_owners_club [DB-005 Critical] - #66
Open
UNIFY-MC wants to merge 1 commit into
Open
fix(db): rename schema v1_owners_club → v10_owners_club [DB-005 Critical]#66UNIFY-MC wants to merge 1 commit into
UNIFY-MC wants to merge 1 commit into
Conversation
…cal]
DB-005 brownfield Critical (2026-05-23): schema com nome errado conforme naming
canónico V1-V10 do CLAUDE.md. Owners Club = V10 (horizontal de fidelidade),
não V1 (Core Hub). Naming conflituante criava risco de queries WHERE schema
LIKE 'v1%' apanharem o schema errado.
AUDIT pré-migration (2026-05-24):
- 3 tabelas: ofertas (6 rows), pontos_historico (0), resgates (0)
- 9 triggers (auto-RI + trg_ofertas_updated_at)
- 4 policies RLS
- 0 funções/RPCs com 'v1_owners_club' em prosrc — ZERO dependências externas
- 1 view externa: public.v_ofertas (SELECT direto de v1_owners_club.ofertas)
- 1 FK interna (resgates → ofertas) — preservada
MIGRATION 202605240200_rename_v10_owners_club.sql aplicada em V1 Core Hub:
PARTE 1: ALTER SCHEMA v1_owners_club RENAME TO v10_owners_club
→ renomeia tabelas + indexes + triggers + policies + FKs automaticamente
PARTE 2: DROP VIEW public.v_ofertas + CREATE VIEW com referência nova
→ PostgreSQL NÃO actualiza view definitions automaticamente
→ GRANT SELECT TO anon, authenticated re-aplicado
PARTE 3: ALTER ROLE authenticator SET pgrst.db_schemas com v10_owners_club
→ substitui v1_owners_club na lista PostgREST exposed schemas
PARTE 4: NOTIFY pgrst, 'reload config'
VALIDATION pós-apply (6 queries — todas PASS):
- schemas: v10_owners_club existe, v1_owners_club desapareceu
- 3 tabelas preservadas
- ofertas_count: 6 ✓
- public.v_ofertas count: 6 ✓
- policies_count: 4 ✓
- fks_count: 3 ✓
CLAUDE.md actualizado:
- Exemplo SQL canónico pgrst.db_schemas: v1_owners_club → v10_owners_club
- Nota DB-005 explica rename + preservação dados
Reversão trivial documentada no header da migration.
Migration idempotente: rerunning falha gracefully (schema já não existe).
Refs: DB-005 (technical-debt-assessment.md), naming canónico V1-V10 (CLAUDE.md)
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
10 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Sumário
v1_owners_club→v10_owners_clubno V1 Core Hub (hkmvszkpxjbxmnixzqbl) — corrige naming conflituante com naming canónico V1-V10 (Owners Club é V10, horizontal de fidelidade, não V1 Core Hub)public.v_ofertas(drop + create com nova referência — PostgreSQL não actualiza view definitions automaticamente após rename)pgrst.db_schemasda roleauthenticatorsubstituindov1_owners_clubporv10_owners_club+NOTIFY pgrst(PostgREST schema exposure conforme ADR-V2-002)Contexto
DB-005 brownfield Critical (technical-debt-assessment.md, 2026-05-23). Schema com nome errado criava risco real: queries auditivas ou de IAM com
WHERE schema_name LIKE 'v1%'apanhariam o Owners Club por engano, e tooling cross-vertical podia assumir wrongly que estes dados pertencem ao Core Hub.Audit pré-migration (2026-05-24)
ofertas(6 rows),pontos_historico(0),resgates(0)trg_ofertas_updated_atALTER SCHEMAresgates → ofertas(preservada)public.v_ofertas(SELECT directo) — actualizada na PARTE 2pgrst.db_schemasEstrutura da migration (4 partes)
ALTER SCHEMA v1_owners_club RENAME TO v10_owners_clubDROP VIEW public.v_ofertas+CREATE VIEW … FROM v10_owners_club.ofertas+GRANT SELECT TO anon, authenticatedALTER ROLE authenticator SET pgrst.db_schemas = '… v10_owners_club …'NOTIFY pgrst, 'reload config'Validação pós-apply (6 queries — todas PASS)
v10_owners_clubexiste empg_namespacev1_owners_clubremovido depg_namespaceSELECT COUNT(*) FROM v10_owners_club.ofertasSELECT COUNT(*) FROM public.v_ofertas(view reapontada)Zero perda de dados. Zero perda de policies. View externa funcional.
Rollback
Reversão trivial — documentada no header de
supabase/migrations/202605240200_rename_v10_owners_club.sql:ALTER SCHEMA v10_owners_club RENAME TO v1_owners_clubpublic.v_ofertasapontando parav1_owners_club.ofertaspgrst.db_schemas+NOTIFY pgrstMigration idempotente: rerunning falha gracefully (schema já não existe).
Ficheiros tocados
supabase/migrations/202605240200_rename_v10_owners_club.sql(novo, 113 linhas)CLAUDE.md(6 linhas) — exemplo SQL canónicopgrst.db_schemasactualizado + nota DB-005Risk assessment
Low risk:
v1_owners_club(Owners Club é V10 futura)prataowners.pt) — schema isolado em outro projecto SupabaseRefs
docs/brownfield-discovery/technical-debt-assessment.mdCLAUDE.md(linhas 11-22).claude/strategy/adrs/ADR-V2-002-postgrest-schema-exposure.md🤖 Generated with Claude Code