TableController Remodel

[nicozsd]

Refatoração e modularização da classe TableController, separando cada manager em seu próprio arquivo, limpando código morto e tornando a arquitetura extensível de forma independente por responsabilidade.

---

CONTEXTO

A TableController atualmente concentra toda a lógica de SELECT, INSERT, UPDATE e DELETE em um único arquivo junto das classes auxiliares (FieldCondition, BinaryExpression, SelectManager, InsertManager, UpdateManager, DeleteManager, wrappers e builders). Isso dificulta manutenção, testes isolados e evolução individual de cada operação.

---

OBJETIVO

• Separar cada manager em seu próprio módulo, mantendo a TableController como ponto de entrada limpo
• Eliminar código morto, comentários obsoletos e lógica duplicada
• Garantir que a API pública permaneça idêntica — nenhuma quebra de contrato com o código consumidor
• Tornar cada manager testável de forma isolada

---

ESTRUTURA PREVISTA

managers/
├── __init__.py
├── conditions.py        → FieldCondition, BinaryExpression
├── select_manager.py    → SelectManager, JoinBuilder, AutoExecuteWrapper
├── insert_manager.py    → InsertManager, InsertRecordsetManager, InsertRecordsetWrapper
├── update_manager.py    → UpdateManager
├── delete_manager.py    → DeleteManager, DeleteRecordsetManager, AutoExecuteDeleteWrapper
└── table_controller.py  → TableController (ponto de entrada — apenas delegação)

---

RESPONSABILIDADES POR MÓDULO

conditions.py — Representa condições de campo e expressões binárias para construção de WHERE. Nenhuma dependência de banco ou controller.

select_manager.py — Gerencia operações SELECT com API fluente, incluindo JOIN, ORDER BY, GROUP BY, HAVING, DISTINCT e processamento de resultados com e sem agregações.

insert_manager.py — Gerencia inserção simples e em massa (insert_recordset), incluindo filtro condicional via NOT EXISTS e bulk insert otimizado.

update_manager.py — Gerencia atualização de registro único e em massa (update_recordset), com validação de RECID e comparação de campos alterados.

delete_manager.py — Gerencia exclusão de registro único e em massa (delete_from), com proteção obrigatória de WHERE.

table_controller.py — Ponto de entrada da API. Delega para os managers, mantém __getattribute__ e __setattr__ para interceptação de campos EDT/Enum, e expõe os métodos públicos: select, insert, update, delete, insert_recordset, update_recordset, delete_from, exists, set_current, clear, validate_fields, validate_write.

---

LIMPEZA PREVISTA

Item	Ação
AutoExecuteWrapper._pending_executions	Remover — lógica de GC desabilitada e não utilizada
AutoExecuteWrapper.__del__	Remover — comentado como desabilitado no próprio código
SelectManager.__get__	Avaliar remoção — nunca é chamado como descriptor neste fluxo
SelectManager._should_auto_execute	Remover — método vazio que não influencia nada
InsertRecordsetWrapper.__del__	Avaliar — auto-execução em __del__ é imprevisível
where_conditions em SelectManager.execute	Corrigir — referência a self.where_conditions (sem underscore) que não existe
Comentários de debug (# print(...))	Remover
Verificações redundantes de or self._group_by is not None após if self._group_by	Simplificar

---

CONTRATO MANTIDO

A API pública não muda. O código consumidor continua funcionando sem alteração:

tabela.select().where(tabela.CAMPO == 5)
tabela.insert()
tabela.update()
tabela.delete()
tabela.insert_recordset(dados).where('CAMPO')
tabela.update_recordset(where=tabela.CAMPO == 5, ATIVO=False)
tabela.delete_from().where(tabela.CAMPO < 10)
tabela.exists(tabela.RECID == 1)

---

NOTAS TÉCNICAS

Nota	Detalhe
Imports	Cada manager importa apenas o que precisa — sem importação cruzada desnecessária
TableController	Passa a importar todos os managers no __init__ e delegar diretamente
Cache estático	_defaults_cache permanece em TableController — é estado de instância da tabela, não do manager
Decorators	@validate_insert, @validate_update, @validate_delete permanecem nos seus respectivos managers
Backward compatibility	Nenhuma mudança de assinatura de método ou comportamento observável

---

NOTA: A refatoração é puramente estrutural. Nenhuma regra de negócio deve ser alterada durante o processo — apenas reorganização e limpeza. Qualquer correção de bug identificada durante a análise deve ser sinalizada separadamente antes de aplicada.

[nicozsd]

Remodelagem da coontroladora table controller finalizado e ja documentado, branch issue1 criada.