Entités (Neon)
Il y a deux façons de travailler avec des données relationnelles (Neon Postgres) depuis une application PRISM :
defineEntity— un générateur d'admin piloté par configuration qui mappe une entité vers un CRUD complet, adossé aux procédures tRPC de company-manager.- Accès direct à Neon — le tagged template
sqldu framework pour des requêtes écrites à la main.
defineEntity
defineEntity réside dans le kit @bext-stack/manage, et non dans le framework
(@bext-stack/framework). C'est la surface console/admin.
defineEntity mappe une seule entité vers des écrans liste / détail / nouveau / édition plus le
CRUD, adossé aux procédures tRPC de company-manager. Il est générique sur les noms des procédures
tRPC — une faute de frappe dans un nom de procédure est une erreur de compilation.
Transport et configuration
Le transport tRPC est cmQuery (GET) / cmMutate (POST), issus du cm.ts du kit. La base, le
tenant et le site proviennent de configureManage(...), appelé une seule fois comme import à
effet de bord :
import { configureManage } from "@bext-stack/manage";
configureManage({
appId: "<app-id>",
cmBase: "…",
host: "…",
origin: "…",
tenantId: "…",
siteId: "…",
});
| Élément | Rôle |
|---|---|
configureManage({ appId, cmBase, host, origin, tenantId, siteId }) |
Configuration unique, à effet de bord, de la base/du tenant/du site. |
cmQuery |
Transport de query tRPC (GET). |
cmMutate |
Transport de mutation tRPC (POST). |
Le motif de ré-export mince
Hébergez une entité générée en ré-exportant le module d'entité du kit depuis un fichier de route — la route reste un simple shim mince :
// src/app/manage/posts/page.tsx
export { loader, default } from "@bext-stack/manage/entities/posts";
Exemple : la base de connaissances du helpdesk
L'entité KB du helpdesk est une vraie configuration defineEntity reliée à ces procédures :
| Procédure | Usage |
|---|---|
helpdeskKb.getArticles |
Lister les articles |
helpdeskKb.getArticleById |
Récupérer un article |
helpdeskKb.getCategories |
Lister les catégories |
Comme defineEntity est générique sur ces noms, renommer ou mal saisir l'un d'eux est détecté à la
compilation. Voir Helpdesk.
Accès direct à Neon
Pour des requêtes écrites à la main, le framework exporte un helper SQL en tagged template :
import { sql, database, POSTGRES_DIALECT } from "@bext-stack/framework";
const posts = await sql`SELECT id, title FROM posts WHERE tenant_id = ${tenantId}`;
| Export | Ce que c'est |
|---|---|
sql |
Helper de requête en tagged template. |
database |
Le handle de base de données. |
POSTGRES_DIALECT |
Le marqueur de dialecte Postgres. |
La chaîne de connexion Neon est récupérée une seule fois via une lecture KV en
loopback de la clé cm:database_url, de sorte que vous n'avez pas à la configurer dans
l'application.
Les interpolations dans le template sql sont paramétrées — passez les valeurs via ${...} plutôt
que de construire des chaînes de requête à la main.
Et ensuite
| Page | Ce qu'elle couvre |
|---|---|
| Modèle de données | Le schéma Neon restreint au tenant et les modèles clés |
| Helpdesk | L'entité KB en contexte |
| Loaders & Actions | Où s'exécutent les lectures/écritures d'entités |
| KV Store | Où cm:database_url est lue |