Files
adaptador-planilhas/docs/cursor-prompts/spreadsheet-adapter/05-DATABASE-MIGRATIONS.md
T
camilafagundesandCursor 6e23f1533b Implementa o MVP do Adaptador de Planilhas no Elo Pro.
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>
2026-10-02 23:02:00 -03:00

2.3 KiB

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.