@nodefony/drizzle 10.0.0-alpha.6 → 10.0.0-alpha.8

package/dist/types/nodefony/src/orm-core/index.d.ts

@@ -9,3 +9,4 @@ export type { DrizzleOrmOptions } from "./DrizzleOrm.js";
 export { DrizzleRepository } from "./DrizzleRepository.js";
 export type { DrizzleDb, DrizzleTable, DrizzleColumn, DrizzleResolvedRelation, } from "./DrizzleRepository.js";
 export { DrizzleTransaction } from "./DrizzleTransaction.js";
+export { seedEntityRow } from "./seedRow.js";

package/dist/types/nodefony/src/orm-core/seedRow.d.ts

@@ -0,0 +1,23 @@
+import type { IEntity } from "@nodefony/orm-core";
+import type { DrizzleOrm } from "./DrizzleOrm.js";
+/**
+ * Insère une ligne minimale dans la table d'une entité, et rend son identifiant.
+ *
+ * Destiné aux **tests** : dès qu'une entité porte une relation (`author:ref:Author`),
+ * sa colonne est une vraie clé étrangère, et la base REFUSE un identifiant
+ * inventé. La ligne parente doit donc exister avant toute insertion — et c'est
+ * la seule façon d'éprouver la contrainte au lieu de la contourner (débrancher
+ * `foreign_keys` rendrait le test vert sans rien prouver).
+ *
+ * Ce qui est rempli : les colonnes **obligatoires sans valeur par défaut**, avec
+ * une valeur du type que Drizzle déclare. Le reste est laissé au schéma — une
+ * clé primaire auto-générée, un horodatage, un défaut applicatif se posent seuls.
+ *
+ * @param orm - la connexion sur laquelle semer.
+ * @param entity - l'entité cible ; son `schema` est la table Drizzle.
+ * @returns l'identifiant de la ligne créée, à poser dans la colonne qui la désigne.
+ * @throws Si la cible porte elle-même une clé étrangère obligatoire — le semis à
+ *   un seul étage ne sait pas la satisfaire, et le message le dit plutôt que de
+ *   laisser remonter un « FOREIGN KEY constraint failed » sans contexte.
+ */
+export declare function seedEntityRow(orm: DrizzleOrm, entity: IEntity): Promise<string | number>;

package/docs/migrations.md

@@ -162,6 +162,34 @@ Le dialecte est celui de votre connecteur : vos entités sont du Drizzle **natif
 un moteur. C'est ce qui vous laisse toute la puissance du moteur dans une entité — et ce qui fait
 qu'une migration vaut pour lui seul.
 
+### En développement : écrire et appliquer d'un seul geste — `--apply`
+
+```bash
+nodefony orm:generate --name ajout_du_titre --apply
+```
+
+Vous éditez votre entité, vous tapez **une** commande, la colonne est en base. C'est le geste
+quotidien du développement, et il ne vous demande pas de retenir un second verbe.
+
+`--apply` n'invente rien : il **enchaîne `orm:migrate`**. Toutes ses gardes valent donc à
+l'identique — une migration qui supprime des données reste refusée sans `--allow-destructive`, le
+verrou est pris, l'historique est écrit. En sortie machine (`--json`), un seul document est produit,
+celui de l'application : c'est lui qui porte le verdict.
+
+> **Le drapeau n'existe qu'en développement**, et aucun autre drapeau ne le déverrouille. Écrire une
+> migration et l'appliquer dans le même souffle suppose qu'on relit le SQL produit entre les deux —
+> ce que personne ne fait sur un serveur. Ailleurs, la migration a été écrite, relue et versionnée
+> ailleurs : c'est `orm:migrate` qui l'applique, et lui seul.
+
+> **Et le mode de schéma bascule tout seul.** Dès que votre application versionne sa première
+> migration, le démarrage cesse de dériver les tables depuis le code (`ddl: "auto"`) et applique vos
+> migrations (`ddl: "migrate"`) — même en développement. Deux fabricants du même schéma ne
+> s'accordent pas : le DDL dérivé pose une unicité **collée à la colonne** (`content text NOT NULL
+UNIQUE`), le générateur de migrations raisonne sur un **index nommé** (`messages_content_unique`),
+> et la première migration qui tente de retirer la seconde échoue sur un objet qui n'a jamais existé.
+> Un `ddl` écrit dans votre configuration gagne toujours ; et sous `NODE_ENV=test`, rien ne change
+> (une suite lance un exemplaire par worker, et ses bases partent vides).
+
 ### Ce que la commande refuse, et pourquoi c'est une bonne nouvelle
 
 **Une migration est immuable dès qu'une base l'a reçue.** Une migration à laquelle il manque une
@@ -201,7 +229,8 @@ réclame aucun outil tiers.
 Déclarer une référence vers une table du framework (`session`, `audit_event`…) est légitime : ce
 qui est refusé, c'est de **ré-exporter** cette table depuis vos fichiers. Les tables du framework
 sont exclues du plan de votre application — elles ont leurs propres migrations, appliquées avant les
-vôtres. Pour une vraie clé étrangère SQL, écrivez une migration libre.
+vôtres. La contrainte, elle, est bien écrite dans votre migration : elle désigne une table que le
+framework a déjà créée.
 
 > [!IMPORTANT]
 > **`User` n'en fait PAS partie.** L'identité est du domaine : la table `User` appartient à votre

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@nodefony/drizzle",
-  "version": "10.0.0-alpha.6",
+  "version": "10.0.0-alpha.8",
   "description": "Moteur SQL de Nodefony sur Drizzle ORM (SQLite, PostgreSQL, MySQL) : dépôts typés, migrations de schéma et adoption d'une base existante",
   "nodefony": {
     "storeKind": "durable",
@@ -57,33 +57,33 @@
   "dependencies": {
     "drizzle-orm": "0.45.2",
     "tslib": "2.8.1",
-    "zod": "^4.6.1"
+    "zod": "^4.6.5"
   },
   "devDependencies": {
-    "@nodefony/framework": "^10.0.0-alpha.6",
-    "@nodefony/http": "^10.0.0-alpha.6",
-    "@nodefony/orm-core": "^10.0.0-alpha.6",
-    "@nodefony/security": "^10.0.0-alpha.6",
-    "@nodefony/user": "^10.0.0-alpha.6",
+    "@nodefony/framework": "^10.0.0-alpha.8",
+    "@nodefony/http": "^10.0.0-alpha.8",
+    "@nodefony/orm-core": "^10.0.0-alpha.8",
+    "@nodefony/security": "^10.0.0-alpha.8",
+    "@nodefony/user": "^10.0.0-alpha.8",
     "@types/better-sqlite3": "9.6.0",
-    "@types/node": "26.5.1",
+    "@types/node": "26.6.2",
     "@types/pg": "8.23.1",
     "better-sqlite3": "13.0.3",
     "drizzle-kit": "0.31.10",
     "mysql2": "3.24.4",
-    "nodefony": "^10.0.0-alpha.6",
+    "nodefony": "^10.0.0-alpha.8",
     "pg": "8.23.0",
     "rimraf": "6.1.3"
   },
   "peerDependencies": {
-    "@nodefony/framework": "^10.0.0-alpha.6",
-    "@nodefony/http": "^10.0.0-alpha.6",
-    "@nodefony/orm-core": "^10.0.0-alpha.6",
-    "@nodefony/security": "^10.0.0-alpha.6",
-    "@nodefony/user": "^10.0.0-alpha.6",
+    "@nodefony/framework": "^10.0.0-alpha.8",
+    "@nodefony/http": "^10.0.0-alpha.8",
+    "@nodefony/orm-core": "^10.0.0-alpha.8",
+    "@nodefony/security": "^10.0.0-alpha.8",
+    "@nodefony/user": "^10.0.0-alpha.8",
     "better-sqlite3": "^13.0.0",
     "mysql2": "^3.24.0",
-    "nodefony": "^10.0.0-alpha.6",
+    "nodefony": "^10.0.0-alpha.8",
     "pg": "^8.23.0"
   },
   "repository": {