Filosofia e Escopo

O Mirror ORM não tenta ser um “canivete suíço” que faz tudo mal feito. Ele foi desenhado para ser um motor de reflexão de dados extremamente magro. Para manter o overhead em 39ns/row, tomamos decisões deliberadas de não implementar certas funcionalidades comuns em ORMs “pesados”.

O que o Mirror NÃO é (e por quê)

Funcionalidade	Status	Por que?
Migrations	Fora de escopo	DDL é uma responsabilidade de infraestrutura. Recomendamos ferramentas especializadas como dbmate, Umzug ou SQL puro.
Validação	Fora de escopo	Validar regras de negócio no mapeamento degrada a performance. Use `class-validator` nos Lifecycle Hooks para validação desacoplada.
Lazy Loading	Não suportado	Lazy loading via Proxies esconde queries assíncronas e causa o problema N+1 silencioso. No Mirror, o carregamento é sempre explícito.
Entity Manager	Não suportado	Evitamos o “God Object” que rastreia tudo. O Mirror é stateless por padrão, garantindo previsibilidade e baixo consumo de memória.
CLI	Não suportado	O Mirror é uma biblioteca de runtime. Não há geração de código ou ferramentas de terminal inclusas no core.

Os Pilares do Mirror

Explicit over Implicit: Você sempre sabe quando uma query está sendo executada. Sem surpresas em getters de propriedades.
Stateless Efficiency: Usamos Snapshotting em vez de Proxies para Dirty Checking. Isso mantém a velocidade de acesso às propriedades da classe idêntica à de um objeto nativo.
JIT Hydration: No bootstrap, compilamos um hidratador específico para cada uma de suas entidades. O V8 otimiza esse código, eliminando loops genéricos durante a leitura de milhares de linhas.

Quando usar o Mirror?

Se você precisa de performance de Raw SQL, mas quer a segurança de tipos do TypeScript.
Se o seu ambiente (Serverless/Edge) exige um Cold Start instantâneo.
Se você quer controle total sobre o que o seu ORM está enviando para o banco de dados.