O módulo usa a identidade Supabase, isola cada workspace e registra storage, TTL, runner e biblioteca XLSX como decisões ainda abertas. Co-authored-by: Cursor <cursoragent@cursor.com>
97 lines
2.3 KiB
Markdown
97 lines
2.3 KiB
Markdown
# PROMPT 05 — Banco de dados e migrations
|
|
|
|
Use o MASTER CONTEXT e as convenções de migrations descobertas no Prompt 02.
|
|
|
|
## Objetivo
|
|
|
|
Criar o schema persistente mínimo do Adaptador, multi-tenant por `workspace_id`, sem duplicar entidades do Elo Pro.
|
|
|
|
## Tabelas alvo
|
|
|
|
Adapte nomenclatura/campos às convenções do repo, preservando a semântica:
|
|
|
|
### spreadsheet_adapter_settings
|
|
- `workspace_id` PK/FK
|
|
- `allow_non_admin_model_upload boolean not null default false`
|
|
- timestamps
|
|
|
|
### spreadsheet_models
|
|
- id
|
|
- workspace_id
|
|
- name lógico
|
|
- original_filename
|
|
- format (`xlsx|csv`)
|
|
- storage_key
|
|
- selected/default sheet quando aplicável
|
|
- header_row
|
|
- `columns_schema jsonb`
|
|
- created_by
|
|
- created_at / updated_at
|
|
- status
|
|
- constraint de nome único ativo por workspace, se compatível com estratégia de exclusão
|
|
|
|
### spreadsheet_jobs
|
|
- id
|
|
- workspace_id
|
|
- user_id
|
|
- model_id
|
|
- status com enum/check coerente
|
|
- source_count
|
|
- current_source
|
|
- output_format
|
|
- progress
|
|
- error_code / error_metadata sanitizada
|
|
- timestamps de ciclo
|
|
|
|
### spreadsheet_job_sources
|
|
- id
|
|
- job_id
|
|
- source_name
|
|
- temp_storage_key
|
|
- selected_sheet
|
|
- header_row
|
|
- row_count
|
|
- size_bytes
|
|
- status
|
|
- expires_at
|
|
|
|
### spreadsheet_job_mappings
|
|
- id
|
|
- job_source_id
|
|
- source_column
|
|
- model_column
|
|
- is_required
|
|
- position
|
|
- unicidade suficiente para garantir 1:1
|
|
|
|
### audit log
|
|
Reutilize o audit log Elo Pro se a estrutura suportar os eventos do módulo. Não crie tabela paralela sem necessidade.
|
|
|
|
## Regras de banco
|
|
|
|
- FKs corretas e cascades cuidadosamente escolhidas.
|
|
- Índices por `workspace_id`, status e relacionamentos frequentes.
|
|
- RLS em todas as tabelas tenant-aware.
|
|
- Constraints para integridade que não dependam só do frontend.
|
|
- Não persistir conteúdo bruto das planilhas no PostgreSQL.
|
|
- Não armazenar segredos.
|
|
|
|
## Decisões abertas
|
|
|
|
Se soft delete vs delete físico ainda estiver aberto, implemente schema que não torne a decisão irreversível e documente a escolha temporária. Não invente política de retenção.
|
|
|
|
## Testes
|
|
|
|
- migrations sobem do zero;
|
|
- rollback/estratégia de reversão documentada;
|
|
- RLS A != B;
|
|
- constraints de duplicidade;
|
|
- 1:1 de mapping;
|
|
- FKs e deleções.
|
|
|
|
## Entrega
|
|
|
|
- migrations;
|
|
- tipos gerados/atualizados conforme padrão Supabase do repo;
|
|
- `docs/spreadsheet-adapter/03-data-model.md` com ERD Mermaid.
|