Tables JSON + colonnes _view

On écrit { json } seulement. Postgres dérive les *_view (GENERATED ALWAYS AS (…) STORED). Les _view existent pour le SQL (PK, FK, UNIQUE, CHECK, INDEX, WHERE, JOIN, SUM) — pas pour le contrat applicatif.

Exception : une FK hors du cycle de vie du json devient une colonne plate, écrite par sa propre méthode de repository — quand chaque transition reconstruit le json champ par champ et qu'un champ de plus s'y perdrait. Référence : project_financing_request."companyId".

Getters

Un getter d'entité (find*, get*, insert* / update* qui relisent la ligne) retourne .json. Les *_view ne leakent pas (id_view, endedAt_view, …). Un SELECT projeté (poll, agrégat) peut lire et aliaser des _view — ce n'est pas un getter d'entité.

Référence : company-internal-fundraising-*.repository.ts.

Quelles colonnes _view

Une _view n'existe que si une requête aujourd'hui s'en sert (contrainte, index, filtre, jointure, agrégat, ou ORDER BY qu'un id_view UUIDv7 time-ordered ne remplace pas).

DO NOT créer une _view « au cas où » — pas de createdAt_view / updatedAt_view pour un tri déjà couvert par id_view.