71 lines
5.3 KiB
Markdown
71 lines
5.3 KiB
Markdown
# Log da Migração Massiva SQL-First (Sessão Completa)
|
|
|
|
## Visão Geral
|
|
Nesta sessão de trabalho, realizamos o "core" da transição do sistema EduManager, saindo do modelo puramente JSON (`school_data.json`) e consolidando 4 módulos centrais diretamente no Banco de Dados Relacional PostgreSQL.
|
|
|
|
## Módulos Migrados
|
|
|
|
### Fase 4: Gestão de Alunos e Autenticação
|
|
- **Backend Manager**: CRUD no `database.js` para tabela `alunos`, com rotas `/api/alunos` e `/api/alunos/:id/rematricular` no `server.selfhosted.js` que executam operações no PostgreSQL e realizam sincronização reversa em tempo real no legado `school_data.json` para total compatibilidade legacy.
|
|
- **Frontend Manager (`Students.tsx`)**: Completamente refatorado para ler e gravar diretamente nas rotas relacionais `/api/alunos`, eliminando 100% das chamadas `dbService.saveData` nesta tela, mantendo apenas o estado em memória sincronizado para continuidade UX.
|
|
- **Portal do Aluno**: Login (`/api/portal/login`) e perfil (`/api/portal/me`) reescritos para consultar a tabela `alunos` no PostgreSQL.
|
|
|
|
|
|
### Fase 5: Avaliações e Provas
|
|
- Backend e Frontend conectados às tabelas `provas` e `questoes_provas`.
|
|
|
|
### Fase 6: Cronograma e Aulas
|
|
- **Backend Manager**: Queries em lote (`insertAulas`, `getAulasByTurma`, `getAllAulas`, `deleteAulas`).
|
|
- **Frontend Manager (`LessonSchedule.tsx`)**: Consome `fetch('/api/aulas')` em estado próprio (`dbLessons`).
|
|
- **Frontend Manager (`Classes.tsx`)**: Ao criar/editar turma e gerar cronograma, agora envia aulas via `POST /api/aulas/lote` para o PostgreSQL.
|
|
- **Portal do Aluno**: Rota `/api/portal/aulas` faz `SELECT FROM aulas WHERE turma_id = ANY(...)`.
|
|
|
|
### Fase 7: Contratos e Modelos
|
|
- **Backend Manager**: CRUD para `contratos` e `modelos_contrato`.
|
|
- **Frontend Manager (`Contracts.tsx`)**: Consome `/api/contratos` e `/api/modelos-contrato`.
|
|
- **Portal do Aluno**: Rota `/api/portal/contratos` faz `SELECT FROM contratos WHERE aluno_id = $1`.
|
|
|
|
## Bugs Encontrados e Corrigidos
|
|
|
|
### 🐛 Bug 1: Tela Branca na Aba Alunos (`Students.tsx`)
|
|
- **Causa**: Referência circular no `useState` — `useState<any[]>(dbClasses || [])` referenciava a si mesma.
|
|
- **Fix**: Alterado para `useState<any[]>(data?.classes || [])`.
|
|
|
|
### 🐛 Bug 2: Dados Não Migrados para PostgreSQL
|
|
- **Causa**: A rotina `syncJsonToRelationalTables` só roda quando o Manager salva o JSON via `PUT /api/school-data`. Como a migração era nova, os dados nunca foram sincronizados.
|
|
- **Fix**: Criado script `migrate_aulas_contratos.cjs` que conecta diretamente ao PostgreSQL de produção e roda os INSERTs.
|
|
- **Resultado**: 109 aulas, 9 contratos, 1 modelo e 89 frequências migrados com sucesso.
|
|
|
|
### 🐛 Bug 3: Aulas Órfãs (FK Constraint)
|
|
- **Causa**: 57 aulas no JSON pertenciam a uma turma deletada (`d48b268c-...`), causando violação de FK.
|
|
- **Fix**: O script filtra aulas cujo `classId` não existe na tabela `turmas`.
|
|
|
|
### 🐛 Bug 4: Contratos Não Apareciam no Manager
|
|
- **Causa**: A função `getContratos()` retornava o campo como `date`, mas o frontend (`Contracts.tsx`) esperava `createdAt`.
|
|
- **Fix**: Corrigido o mapeamento em `database.js` para retornar `createdAt: r.created_at_fmt`.
|
|
|
|
### 🐛 Bug 5: Classes.tsx Não Salvava Aulas no PostgreSQL
|
|
- **Causa**: Ao criar/editar turma com cronograma, as aulas geradas eram salvas **apenas no JSON** (`data.lessons`), nunca no banco.
|
|
- **Fix**: Adicionado `fetch('/api/aulas/lote')` no `Classes.tsx` para enviar as aulas geradas ao PostgreSQL.
|
|
|
|
## Estado Final do Banco de Dados
|
|
| Tabela | Registros |
|
|
|---|---|
|
|
| alunos | 9 |
|
|
| aulas | 109 |
|
|
| contratos | 9 |
|
|
| frequencias | 89 |
|
|
| modelos_contrato | 1 |
|
|
| provas | 3 |
|
|
| turmas | 3 |
|
|
|
|
## Padrões de Arquitetura
|
|
1. **Reverse Sync (Mão Dupla)**: Frontend salva no SQL via API e mantém backup no JSON.
|
|
2. **Fallback Gradual**: Portal prioriza SQL, invoca JSON apenas se banco retornar vazio.
|
|
3. **Migração de Dados**: Executada via script Node.js conectando diretamente ao PostgreSQL de produção (host: `150.230.87.131`, user: `edumanager`).
|
|
### Fase 8: Consolidação de Frequência, Registro de Matrículas e Contratos Relacionais
|
|
- **Justificativa Única Rígida (Portal)**: Implementação de regra de validação rígida impedindo que o aluno envie mais de uma justificativa por aula. O Portal do Aluno agora exibe um aviso dinâmico informando que a aula já possui justificativa e desativa o envio. O backend valida a existência e retorna erro HTTP 400.
|
|
- **Sincronização Direta de Contratos (Manager)**: O fluxo de salvamento de matrículas foi aprimorado para disparar uma chamada de `POST /api/contratos` em tempo real ao salvar o aluno, escrevendo a emissão do contrato diretamente no PostgreSQL na VPS.
|
|
- **Refinamento do Modal de Alunos (Manager)**: O checkbox "Gerar Taxa" foi inteiramente removido do modal de matrícula. O checkbox "Gerar Contrato Automático" agora vem selecionado (`true`) por padrão em novos cadastros e desmarcado (`false`) ao editar matrículas para prevenir duplicações acidentais.
|
|
- **Relatório de Frequência Geral em PDF (Manager)**: Refatoração do exportador de PDF no módulo Registro de Frequência para gerar uma Ficha de Frequência Geral (Roster de todos os alunos ativos da turma, com contagem acumulada de presenças, faltas, justificativas e porcentagem de frequência de cada um) de modo a corresponder perfeitamente ao que o administrador visualiza na modal, eliminando downloads vazios.
|