0007 — Micronaut Data JDBC sem Hibernate

Status: Aprovado · Responsável: Gustavo Madruga · Atualizado em: 2026-07-06 · Decidido em: 2026-04-01

Contexto

O processador persiste dimensões e fatos (bi_*) e metadados (xls_*) em PostgreSQL. O pipeline depende de SQL fino: UPSERT diff-aware com ON CONFLICT DO UPDATE WHERE IS DISTINCT FROM, DELETE seletivo por período e — crucialmente — executeBatch() retornando rowCount per-row para alimentar a métrica linhas_efetivas (spec 003). A camada de dados precisava dar esse controle.

Decisão

Usar Micronaut Data JDBC — repositórios sobre entidades @MappedEntity — sem Hibernate/JPA. O schema é versionado exclusivamente por Flyway (classpath:db/migration, histórico bi_comercial_flyway_schema_history), nunca por DDL automático de ORM.

Consequências

• Controle explícito do SQL — pré-requisito do BulkUpsert (PreparedStatement + executeBatch) e das métricas per-row (ver 0009).
• Sem cache de 1º nível, lazy-loading ou flush implícito surpreendendo o fluxo assíncrono.
• Migrações revisáveis em PR; sem divergência entre modelo Java e banco.

Alternativas consideradas

• Hibernate/JPA: abstrai o SQL demais; o SQL implícito atrapalharia o controle per-row que a métrica linhas_efetivas exige. Descartado.
• JDBC puro / JdbcTemplate manual: daria o controle, mas os repositórios @MappedEntity reduzem boilerplate sem perder o SQL cru onde importa. Descartado por reinventar o que o Data JDBC já entrega.