@vibeorm/migrate 1.3.1 → 2.0.0-alpha.10

package/dist/recovery.d.ts

@@ -0,0 +1,41 @@
+/**
+ * Establishing what actually happened, before a nontransactional migration
+ * re-runs anything.
+ *
+ * A migration that runs outside a transaction can die between a statement
+ * committing and the journal recording it. The only honest recovery is to ask
+ * the database what the world looks like now and compare it against the
+ * statement's DECLARED postcondition (execution.ts). Three answers exist:
+ *
+ * - `"satisfied"` — the live catalog already matches the declaration. Skip it.
+ * - `"runnable"` — the declaration is demonstrably not in effect, and running
+ *   the statement is the way to get there.
+ * - a thrown `VibeError` — the state is neither, and no automatic action is
+ *   safe. Nothing is dropped, nothing is re-run: the operator decides.
+ *
+ * There is deliberately NO fourth answer of the form "probably fine, re-run
+ * it". This module never claims exactly-once execution of arbitrary SQL; it
+ * only decides the cases a declared postcondition can actually settle.
+ *
+ * Comparison is conservative by design. Expressions must match verbatim apart
+ * from surrounding whitespace. Quotes and whitespace inside literals can change
+ * meaning; any difference is a CONFLICT — a false conflict costs an operator one
+ * look, a false match corrupts a schema.
+ */
+import type { Dialect } from "@vibeorm/schema";
+import type { MigrationOperation } from "./execution.ts";
+import type { SqlExecutor } from "./types.ts";
+/** Whether a declared operation's postcondition already holds. */
+export type OperationState = "satisfied" | "runnable";
+/**
+ * Ask the database whether a declared operation is already in effect.
+ *
+ * PostgreSQL only: it is the one dialect with a nontransactional migration
+ * regime here, and every probe reads its catalogs.
+ */
+export declare function establishOperationState(params: {
+    executor: SqlExecutor;
+    dialect: Dialect;
+    operation: MigrationOperation;
+}): Promise<OperationState>;
+//# sourceMappingURL=recovery.d.ts.map

package/dist/recovery.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"recovery.d.ts","sourceRoot":"","sources":["../src/recovery.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;GAuBG;AAGH,OAAO,KAAK,EAAE,OAAO,EAAE,MAAM,iBAAiB,CAAC;AAS/C,OAAO,KAAK,EAAE,kBAAkB,EAAE,MAAM,gBAAgB,CAAC;AACzD,OAAO,KAAK,EAAE,WAAW,EAAE,MAAM,YAAY,CAAC;AAE9C,kEAAkE;AAClE,MAAM,MAAM,cAAc,GAAG,WAAW,GAAG,UAAU,CAAC;AA6BtD;;;;;GAKG;AACH,wBAAsB,uBAAuB,CAAC,MAAM,EAAE;IACpD,QAAQ,EAAE,WAAW,CAAC;IACtB,OAAO,EAAE,OAAO,CAAC;IACjB,SAAS,EAAE,kBAAkB,CAAC;CAC/B,GAAG,OAAO,CAAC,cAAc,CAAC,CAkG1B"}

package/dist/relations.d.ts

@@ -0,0 +1,40 @@
+/**
+ * Implicit many-to-many detection on Schema IR.
+ *
+ * ONE structural rule in @vibeorm/schema, also used by RLS validation and
+ * matching the parser's ambiguity rule (see LEARNINGS): two fields form an
+ * implicit M:N **iff** both are lists that declare no FK columns, they are
+ * distinct fields (self-exclusion — a 1:N self-relation must never pair with
+ * itself), their relation names match symmetrically (both unnamed, or both
+ * the same name), and each side is the OTHER'S SOLE counterpart under that
+ * name key. Detection never reads `relation.type`, because an introspected
+ * schema represents a real join table as two unnamed `oneToMany` list sides —
+ * trusting the type would break round-trip stability.
+ *
+ * The sole-counterpart requirement is the phantom-join-table fix, round two:
+ * two models holding foreign keys INTO EACH OTHER introspect as an unnamed
+ * fieldless list on each side (every FK synthesizes one on its target), and
+ * name-matching alone would marry those lists into a join table that exists
+ * nowhere. Counting EVERY relation under the name key — FK-owning sides
+ * included — disambiguates: the parser rejects the same shape as
+ * `ambiguous-relation` at parse time, so parsed and introspected schemas
+ * resolve identically.
+ *
+ * The join-table naming itself comes from the ONE shared convention in
+ * `@vibeorm/schema` (`implicitJoinTable`) — never re-derived here.
+ */
+import type { SchemaIR } from "@vibeorm/schema";
+/** A detected implicit many-to-many relation. `modelA` sorts before `modelB`. */
+export type ImplicitM2MPair = {
+    readonly modelA: string;
+    readonly modelB: string;
+    /** Shared explicit relation name, when both sides declare one. */
+    readonly relationName?: string;
+    /** Join table name per the shared convention (`_PostToTag`, `_tags`). */
+    readonly tableName: string;
+};
+/** Detect every implicit many-to-many pair in a schema. */
+export declare function detectImplicitM2MPairs(params: {
+    schema: SchemaIR;
+}): ImplicitM2MPair[];
+//# sourceMappingURL=relations.d.ts.map

package/dist/relations.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"relations.d.ts","sourceRoot":"","sources":["../src/relations.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;GAwBG;AAGH,OAAO,KAAK,EAAE,QAAQ,EAAE,MAAM,iBAAiB,CAAC;AAEhD,iFAAiF;AACjF,MAAM,MAAM,eAAe,GAAG;IAC5B,QAAQ,CAAC,MAAM,EAAE,MAAM,CAAC;IACxB,QAAQ,CAAC,MAAM,EAAE,MAAM,CAAC;IACxB,kEAAkE;IAClE,QAAQ,CAAC,YAAY,CAAC,EAAE,MAAM,CAAC;IAC/B,yEAAyE;IACzE,QAAQ,CAAC,SAAS,EAAE,MAAM,CAAC;CAC5B,CAAC;AAEF,2DAA2D;AAC3D,wBAAgB,sBAAsB,CAAC,MAAM,EAAE;IAAE,MAAM,EAAE,QAAQ,CAAA;CAAE,GAAG,eAAe,EAAE,CA4BtF"}

package/dist/renames.d.ts

@@ -0,0 +1,58 @@
+/**
+ * EXPLICIT physical renames.
+ *
+ * The differ deliberately has no rename detection: two schemas that differ by
+ * a name are indistinguishable from a drop plus a create, and guessing between
+ * them from "similar shapes" is how a migration tool silently destroys a
+ * column. A rename therefore only ever happens because someone WROTE one down,
+ * as an old physical name and a new physical name, and it is validated against
+ * both schemas before a single statement is rendered.
+ *
+ * `@map` / `@@map` remains the no-DDL option: mapping a model or field to the
+ * name the database already uses changes generated code only. Use a rename
+ * intent when the DATABASE object must actually move.
+ *
+ * What a physical rename preserves, on every dialect that supports it: the
+ * rows, the column defaults, the indexes and constraints attached to the
+ * object, and inbound foreign keys — the object keeps its identity, only its
+ * name changes. PostgreSQL policy expressions follow the rename too, because
+ * they are stored parsed and reference the object by identity, not by text.
+ *
+ * What refuses instead of guessing: renaming a table and one of its columns in
+ * the same plan (the second intent's table name is then ambiguous), an intent
+ * whose endpoints do not both check out against the two schemas, and two
+ * intents pointing at the same object.
+ */
+import type { Dialect, SchemaIR } from "@vibeorm/schema";
+import type { MigrationStep } from "./types.ts";
+/** One deliberately written rename, in PHYSICAL (database) names. */
+export type RenameIntent = {
+    readonly kind: "table";
+    readonly from: string;
+    readonly to: string;
+} | {
+    readonly kind: "column";
+    readonly table: string;
+    readonly from: string;
+    readonly to: string;
+};
+/**
+ * Validate rename intents against the two schemas and turn them into steps,
+ * returning the SOURCE schema rewritten as if the renames had happened.
+ *
+ * The rewrite is what keeps the rest of the diff honest: once the source model
+ * carries the new physical name, the ordinary differ sees one table on both
+ * sides and emits no drop/create pair for it. Only `dbName` moves — the
+ * logical IR graph (relations, index field lists) is untouched, so nothing
+ * downstream has to know a rename happened.
+ */
+export declare function planRenames(params: {
+    from: SchemaIR;
+    to: SchemaIR;
+    renames: readonly RenameIntent[];
+    dialect: Dialect;
+}): {
+    readonly steps: readonly MigrationStep[];
+    readonly from: SchemaIR;
+};
+//# sourceMappingURL=renames.d.ts.map

package/dist/renames.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"renames.d.ts","sourceRoot":"","sources":["../src/renames.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;GAwBG;AAGH,OAAO,KAAK,EAAE,OAAO,EAAW,QAAQ,EAAE,MAAM,iBAAiB,CAAC;AAClE,OAAO,KAAK,EAAE,aAAa,EAAE,MAAM,YAAY,CAAC;AAEhD,qEAAqE;AACrE,MAAM,MAAM,YAAY,GACpB;IAAE,QAAQ,CAAC,IAAI,EAAE,OAAO,CAAC;IAAC,QAAQ,CAAC,IAAI,EAAE,MAAM,CAAC;IAAC,QAAQ,CAAC,EAAE,EAAE,MAAM,CAAA;CAAE,GACtE;IAAE,QAAQ,CAAC,IAAI,EAAE,QAAQ,CAAC;IAAC,QAAQ,CAAC,KAAK,EAAE,MAAM,CAAC;IAAC,QAAQ,CAAC,IAAI,EAAE,MAAM,CAAC;IAAC,QAAQ,CAAC,EAAE,EAAE,MAAM,CAAA;CAAE,CAAC;AAuBpG;;;;;;;;;GASG;AACH,wBAAgB,WAAW,CAAC,MAAM,EAAE;IAClC,IAAI,EAAE,QAAQ,CAAC;IACf,EAAE,EAAE,QAAQ,CAAC;IACb,OAAO,EAAE,SAAS,YAAY,EAAE,CAAC;IACjC,OAAO,EAAE,OAAO,CAAC;CAClB,GAAG;IAAE,QAAQ,CAAC,KAAK,EAAE,SAAS,aAAa,EAAE,CAAC;IAAC,QAAQ,CAAC,IAAI,EAAE,QAAQ,CAAA;CAAE,CAkGxE"}

package/dist/runner.d.ts

@@ -0,0 +1,181 @@
+/**
+ * Migration runner: generate named migrations from IR diffs, apply them with
+ * bookkeeping in `_vibe_migrations`, report status, and repair records.
+ *
+ * Concurrency: `applyMigrations` and `rollbackMigration` take an advisory lock
+ * for the whole run — `pg_advisory_lock(1447645253)` on postgres ("VIBE" in
+ * ASCII, blocking, released in a finally), `GET_LOCK('vibeorm_migrate', 60)`
+ * on mysql (throws VIBE_MIGRATION on timeout). sqlite needs none: it is
+ * single-writer and `BEGIN` serializes. Locks are session-scoped — the
+ * SqlExecutor contract (types.ts) requires one session for the whole
+ * operation.
+ *
+ * Lock ORDER matters: the lock is taken BEFORE `ensureMigrationsTable`, never
+ * after. Two concurrent first-time runs against a fresh postgres database
+ * would otherwise both issue `CREATE TABLE IF NOT EXISTS _vibe_migrations`,
+ * which is a catalog race on postgres (a duplicate-key error on
+ * `pg_type_typname_nsp_index`, not a no-op). `migrationStatus` and
+ * `resolveMigration` deliberately take NO lock — wrapping reads in the
+ * migration lock would make `status` block behind a running migrate — so two
+ * concurrent FIRST-EVER `status`/`resolve` calls on a fresh database can still
+ * hit that race; retrying either is enough, since the table then exists.
+ *
+ * Execution strategy per dialect (`DIALECT_CAPABILITIES[dialect]`) AND per
+ * script:
+ *
+ * - transactionalDdl (postgres, sqlite): each migration runs inside
+ *   BEGIN/COMMIT with its bookkeeping INSERT — atomic.
+ * - EXCEPT sqlite scripts containing a table-rebuild block, which manage their
+ *   own transactions (execute.ts `usesSelfManagedTransactions`) and therefore
+ *   cannot be wrapped. Those take the SAME per-statement bookkeeping as mysql
+ *   (below). They are NOT simply "re-runnable": a pure rebuild block is
+ *   effectively idempotent, but any plain statement in the same script
+ *   auto-commits on its own, so without a recorded statement_index a crash
+ *   wedged the migration forever (every later run replayed statements that had
+ *   already run). Resuming into a rebuild block rewinds to that block's
+ *   `PRAGMA foreign_keys=OFF` (execute.ts `selfManagedResumeStart`): the block
+ *   is transactional, so nothing of it survived, and the pragma is
+ *   session-scoped and gone after a crash.
+ * - mysql (transactionalDdl: false — DDL auto-commits): the runner records
+ *   PER-STATEMENT progress instead. The row is inserted up front
+ *   (statement_index 0), advanced after every statement, and on failure the
+ *   error lands in the `error` column. Re-running RESUMES from the recorded
+ *   statement_index — and REFUSES if the migration's checksum changed since
+ *   the partial application. A row is "complete" when its statement_index
+ *   reaches the statement count (or its checksum is empty — resolveMigration
+ *   records, which store statement_index 2147483647).
+ *
+ * `usesStatementBookkeeping` is the ONE predicate deciding which of the two
+ * regimes a (dialect, script) pair is in; apply, status and rollback all read
+ * it, so they can never disagree about whether a record is complete.
+ *
+ * Checksums (sha256 over the joined SQL) pin a migration's content:
+ * re-applying a renamed-or-edited migration is a VIBE_MIGRATION error, never
+ * a silent divergence.
+ */
+import type { Dialect, SchemaIR, VibeExtension } from "@vibeorm/schema";
+import type { MigrationExecution } from "./execution.ts";
+import type { RenameIntent } from "./renames.ts";
+import type { AppliedResult, MigrationFile, MigrationStatus, RecordedMigration, SqlExecutor } from "./types.ts";
+export { MIGRATIONS_TABLE_NAME } from "./journal-table.ts";
+/** Create the bookkeeping table when missing. */
+export declare function ensureMigrationsTable(params: {
+    executor: SqlExecutor;
+    dialect?: Dialect;
+}): Promise<void>;
+/**
+ * sha256 hex over the migration's statements — its identity across runs.
+ *
+ * A NON-default execution block (execution.ts) folds a canonical description
+ * of itself in, so changing how a migration executes after it was applied is
+ * caught by the same checksum refusal that catches changing its SQL. A default
+ * or absent block contributes NOTHING, which is what keeps every migration
+ * written before this feature — and every journal row recording one — valid.
+ */
+export declare function migrationChecksum(params: {
+    sql: readonly string[];
+    execution?: MigrationExecution;
+}): string;
+/**
+ * Diff two IRs and render a named migration for a dialect (postgres if
+ * omitted). `destructive` aggregates the steps' flags so callers can gate
+ * confirmation before applying.
+ */
+export declare function generateMigration(params: {
+    from: SchemaIR;
+    to: SchemaIR;
+    name: string;
+    /** Rendering dialect; postgres if omitted. */
+    dialect?: Dialect;
+    /** Configured extension instances — their artifacts land in the migration. */
+    extensions?: readonly VibeExtension[];
+    /** Explicit physical renames (renames.ts); never inferred from the diff. */
+    renames?: readonly RenameIntent[];
+    /** Explicit execution semantics for the generated file. */
+    execution?: MigrationExecution;
+}): MigrationFile;
+/**
+ * Apply migrations in order under an advisory lock (see module doc).
+ * Already-recorded migrations are checksum-verified and skipped; a mismatch
+ * throws VIBE_MIGRATION (a recorded migration whose SQL changed is
+ * corruption, not drift to paper over). Where progress is recorded per
+ * statement (mysql, and self-managed sqlite scripts), a partially-applied
+ * migration RESUMES from its recorded statement_index. Records created by
+ * `resolveMigration` (empty checksum) skip verification.
+ */
+export declare function applyMigrations(params: {
+    executor: SqlExecutor;
+    migrations: readonly MigrationFile[];
+    acceptSecurityChanges?: boolean;
+    /** Execution dialect; postgres if omitted. */
+    dialect?: Dialect;
+}): Promise<AppliedResult>;
+/** Compare known migrations against the bookkeeping table. */
+export declare function migrationStatus(params: {
+    executor: SqlExecutor;
+    migrations: readonly MigrationFile[];
+    /** Bookkeeping dialect; postgres if omitted. */
+    dialect?: Dialect;
+    /** Trusted current deployment; policy state is verified independently of migration records. */
+    schema?: SchemaIR;
+}): Promise<MigrationStatus>;
+/**
+ * The bookkeeping journal itself, in the order rows were written — i.e. the
+ * order migrations were actually applied, which is what a rollback must walk
+ * backwards. Every row is returned and classified, including the ones
+ * `migrationStatus` folds away: a mismatched record, a partially applied one
+ * and a record whose file is gone all still occupy a position in history, and
+ * a caller that skips them rolls back the WRONG migration (F28).
+ *
+ * Takes no lock, exactly like `migrationStatus`.
+ */
+export declare function recordedMigrations(params: {
+    executor: SqlExecutor;
+    /** Known migration files — classification needs their SQL. */
+    migrations: readonly MigrationFile[];
+    /** Bookkeeping dialect; postgres if omitted. */
+    dialect?: Dialect;
+}): Promise<RecordedMigration[]>;
+/**
+ * Repair the bookkeeping table without running SQL: mark a migration as
+ * `"applied"` (upsert its record; pass `checksum` to also pin its content —
+ * omitted, the record stores an empty checksum and later runs skip
+ * verification for it) or `"rolled-back"` (delete its record).
+ */
+export declare function resolveMigration(params: {
+    executor: SqlExecutor;
+    name: string;
+    as: "applied" | "rolled-back";
+    checksum?: string;
+    /** Bookkeeping dialect; postgres if omitted. */
+    dialect?: Dialect;
+}): Promise<void>;
+/**
+ * Roll back ONE applied migration by executing its `downSql` and deleting its
+ * bookkeeping row, under the same advisory lock as `applyMigrations`.
+ *
+ * Guards, in order: the migration must carry `downSql` (older migrations
+ * predate down-migration support), must be recorded as applied, and — when
+ * the record pins a checksum — its up SQL must still match (rolling back with
+ * drifted files would run a down that no longer mirrors what was applied).
+ *
+ * Dialect behavior mirrors apply exactly (same `usesStatementBookkeeping`
+ * predicate, read over the DOWN script): postgres/sqlite run the down inside
+ * BEGIN/COMMIT with the bookkeeping DELETE (atomic). mysql DDL auto-commits,
+ * and a sqlite down containing a table-rebuild block cannot be wrapped, so
+ * both record progress per-statement in the existing `statement_index`
+ * column, NEGATIVE to mark the rollback direction: after k down statements,
+ * the row stores -(k+1). A failed rollback resumes from the recorded
+ * statement on the next call; `applyMigrations` refuses a mid-rollback record
+ * (that check reads the sign only, so it holds for every dialect). A
+ * partially APPLIED migration cannot be rolled back — its down mirrors the
+ * full up; finish applying (apply resumes) or repair with `resolveMigration`.
+ */
+export declare function rollbackMigration(params: {
+    executor: SqlExecutor;
+    migration: MigrationFile;
+    acceptSecurityChanges?: boolean;
+    /** Execution dialect; postgres if omitted. */
+    dialect?: Dialect;
+}): Promise<void>;
+//# sourceMappingURL=runner.d.ts.map

package/dist/runner.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"runner.d.ts","sourceRoot":"","sources":["../src/runner.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAsDG;AAIH,OAAO,KAAK,EAAE,OAAO,EAAE,QAAQ,EAAE,aAAa,EAAE,MAAM,iBAAiB,CAAC;AAUxE,OAAO,KAAK,EAAE,kBAAkB,EAAE,MAAM,gBAAgB,CAAC;AAEzD,OAAO,KAAK,EAAE,YAAY,EAAE,MAAM,cAAc,CAAC;AAqBjD,OAAO,KAAK,EACV,aAAa,EACb,aAAa,EACb,eAAe,EACf,iBAAiB,EACjB,WAAW,EACZ,MAAM,YAAY,CAAC;AAoFpB,OAAO,EAAE,qBAAqB,EAAE,MAAM,oBAAoB,CAAC;AAsC3D,iDAAiD;AACjD,wBAAsB,qBAAqB,CAAC,MAAM,EAAE;IAClD,QAAQ,EAAE,WAAW,CAAC;IACtB,OAAO,CAAC,EAAE,OAAO,CAAC;CACnB,GAAG,OAAO,CAAC,IAAI,CAAC,CAEhB;AAED;;;;;;;;GAQG;AACH,wBAAgB,iBAAiB,CAAC,MAAM,EAAE;IACxC,GAAG,EAAE,SAAS,MAAM,EAAE,CAAC;IACvB,SAAS,CAAC,EAAE,kBAAkB,CAAC;CAChC,GAAG,MAAM,CAGT;AAUD;;;;GAIG;AACH,wBAAgB,iBAAiB,CAAC,MAAM,EAAE;IACxC,IAAI,EAAE,QAAQ,CAAC;IACf,EAAE,EAAE,QAAQ,CAAC;IACb,IAAI,EAAE,MAAM,CAAC;IACb,8CAA8C;IAC9C,OAAO,CAAC,EAAE,OAAO,CAAC;IAClB,8EAA8E;IAC9E,UAAU,CAAC,EAAE,SAAS,aAAa,EAAE,CAAC;IACtC,4EAA4E;IAC5E,OAAO,CAAC,EAAE,SAAS,YAAY,EAAE,CAAC;IAClC,2DAA2D;IAC3D,SAAS,CAAC,EAAE,kBAAkB,CAAC;CAChC,GAAG,aAAa,CAgChB;AAID;;;;;;;;GAQG;AACH,wBAAsB,eAAe,CAAC,MAAM,EAAE;IAC5C,QAAQ,EAAE,WAAW,CAAC;IACtB,UAAU,EAAE,SAAS,aAAa,EAAE,CAAC;IACrC,qBAAqB,CAAC,EAAE,OAAO,CAAC;IAChC,8CAA8C;IAC9C,OAAO,CAAC,EAAE,OAAO,CAAC;CACnB,GAAG,OAAO,CAAC,aAAa,CAAC,CA4EzB;AAID,8DAA8D;AAC9D,wBAAsB,eAAe,CAAC,MAAM,EAAE;IAC5C,QAAQ,EAAE,WAAW,CAAC;IACtB,UAAU,EAAE,SAAS,aAAa,EAAE,CAAC;IACrC,gDAAgD;IAChD,OAAO,CAAC,EAAE,OAAO,CAAC;IAClB,+FAA+F;IAC/F,MAAM,CAAC,EAAE,QAAQ,CAAC;CACnB,GAAG,OAAO,CAAC,eAAe,CAAC,CA0C3B;AAED;;;;;;;;;GASG;AACH,wBAAsB,kBAAkB,CAAC,MAAM,EAAE;IAC/C,QAAQ,EAAE,WAAW,CAAC;IACtB,8DAA8D;IAC9D,UAAU,EAAE,SAAS,aAAa,EAAE,CAAC;IACrC,gDAAgD;IAChD,OAAO,CAAC,EAAE,OAAO,CAAC;CACnB,GAAG,OAAO,CAAC,iBAAiB,EAAE,CAAC,CA2B/B;AAID;;;;;GAKG;AACH,wBAAsB,gBAAgB,CAAC,MAAM,EAAE;IAC7C,QAAQ,EAAE,WAAW,CAAC;IACtB,IAAI,EAAE,MAAM,CAAC;IACb,EAAE,EAAE,SAAS,GAAG,aAAa,CAAC;IAC9B,QAAQ,CAAC,EAAE,MAAM,CAAC;IAClB,gDAAgD;IAChD,OAAO,CAAC,EAAE,OAAO,CAAC;CACnB,GAAG,OAAO,CAAC,IAAI,CAAC,CAsBhB;AAID;;;;;;;;;;;;;;;;;;;;GAoBG;AACH,wBAAsB,iBAAiB,CAAC,MAAM,EAAE;IAC9C,QAAQ,EAAE,WAAW,CAAC;IACtB,SAAS,EAAE,aAAa,CAAC;IACzB,qBAAqB,CAAC,EAAE,OAAO,CAAC;IAChC,8CAA8C;IAC9C,OAAO,CAAC,EAAE,OAAO,CAAC;CACnB,GAAG,OAAO,CAAC,IAAI,CAAC,CAkEhB"}

package/dist/sqlite-types.d.ts

@@ -0,0 +1,101 @@
+/**
+ * SQLite column-type mapping (IR → storage class and back), comparison keys,
+ * default rendering/fingerprints, and the enum CHECK-constraint convention.
+ *
+ * dialect-matrix §2: sqlite columns use the four storage classes only —
+ * String/DateTime/Decimal/Json → TEXT, Boolean/Int/BigInt → INTEGER,
+ * Float → REAL, Bytes → BLOB. Enums are TEXT plus a named CHECK constraint
+ * (`CONSTRAINT "<table>_<column>_enum_<Enum>" CHECK ("<column>" IN (…))`) —
+ * the constraint NAME is the marker that lets introspection recover the enum's
+ * name, and the IN list recovers its values. Scalar lists are unsupported
+ * (refused by the differ; this module throws as the render-time backstop).
+ *
+ * THE TEXT AMBIGUITY, stated honestly: DateTime, Decimal and Json all live in
+ * TEXT, and Boolean/BigInt live in INTEGER — a pulled schema reports such
+ * columns as String/Int (there is no marker to say otherwise). Column
+ * comparison is therefore STORAGE-CLASS based on sqlite (`sqliteColumnTypeKey`
+ * compares what the database actually stores), so `diff(introspect(push(X)),
+ * X)` stays [] even though the introspected IR says String where X said
+ * DateTime.
+ */
+import type { FieldIR, ScalarType } from "@vibeorm/schema";
+import type { EnumIR } from "@vibeorm/schema";
+/** IR scalar → sqlite storage class. */
+export declare const SCALAR_TO_SQLITE: Readonly<Record<ScalarType, string>>;
+/** Render-time backstop for scalar-list columns (the differ refuses earlier). */
+export declare function refuseSqliteScalarList(params: {
+    field: FieldIR;
+}): never;
+/**
+ * Storage class for a column. Unsupported columns render their nativeType
+ * verbatim (fidelity over guessing); enums are TEXT (the CHECK is separate).
+ */
+export declare function sqliteStorageType(params: {
+    field: FieldIR;
+}): string;
+/**
+ * Comparison key for a column on sqlite: the STORAGE CLASS, not the IR type —
+ * String and DateTime are both `t:TEXT` because the database cannot tell them
+ * apart. Enum columns key on their VALUE LIST (`e:A|B`), never their name
+ * (the name only lives in our CHECK-constraint convention): adding an enum
+ * value changes the key and flows through `alterColumn` → table rebuild with
+ * the widened CHECK.
+ */
+export declare function sqliteColumnTypeKey(params: {
+    field: FieldIR;
+    enums: ReadonlyMap<string, EnumIR>;
+}): string;
+/**
+ * Default fingerprint on sqlite: postgres rules, except booleans compare as
+ * their INTEGER storage (`true` → `num:1`) — an introspected sqlite schema can
+ * only ever report `DEFAULT 1`, and the fingerprint must not churn on that.
+ */
+export declare function sqliteDefaultFingerprint(params: {
+    field: FieldIR;
+}): string | null;
+/**
+ * Render the `DEFAULT` expression for a field on sqlite, or `undefined` when
+ * the column takes none (app-level generators, autoincrement — which renders
+ * as `INTEGER PRIMARY KEY AUTOINCREMENT` instead). Booleans store as 1/0.
+ */
+export declare function sqliteDefaultSql(params: {
+    field: FieldIR;
+}): string | undefined;
+/**
+ * Name of the enum CHECK constraint for a column — the `_enum_` infix is the
+ * introspection marker that recovers the enum's name from `sqlite_master.sql`.
+ */
+export declare function sqliteEnumCheckName(params: {
+    table: string;
+    column: string;
+    enumName: string;
+}): string;
+/** One parsed enum CHECK constraint from a table's `sqlite_master.sql`. */
+export type ParsedEnumCheck = {
+    readonly column: string;
+    readonly enumName: string;
+    readonly values: readonly string[];
+};
+/** One parsed NAMED user CHECK from a table's `sqlite_master.sql`. */
+export type ParsedNamedCheck = {
+    readonly name: string;
+    readonly expression: string;
+};
+/**
+ * Every `CONSTRAINT "name" CHECK (…)` in a table's `sqlite_master.sql`, with
+ * a balanced-paren walk for the expression (a regex capture would stop at the
+ * first `)`). The caller filters out the enum-convention names — those are
+ * column machinery, not user checks.
+ */
+export declare function parseSqliteNamedChecks(params: {
+    tableSql: string;
+}): ParsedNamedCheck[];
+/**
+ * Recover enum columns from a table's `sqlite_master.sql` text. Only checks
+ * following OUR naming convention are recognized; foreign CHECK constraints
+ * are ignored (and — documented limitation — do not survive a table rebuild).
+ */
+export declare function parseSqliteEnumChecks(params: {
+    tableSql: string;
+}): ParsedEnumCheck[];
+//# sourceMappingURL=sqlite-types.d.ts.map

package/dist/sqlite-types.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"sqlite-types.d.ts","sourceRoot":"","sources":["../src/sqlite-types.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;GAmBG;AAGH,OAAO,KAAK,EAAE,OAAO,EAAE,UAAU,EAAE,MAAM,iBAAiB,CAAC;AAG3D,OAAO,KAAK,EAAE,MAAM,EAAE,MAAM,iBAAiB,CAAC;AAI9C,wCAAwC;AACxC,eAAO,MAAM,gBAAgB,EAAE,QAAQ,CAAC,MAAM,CAAC,UAAU,EAAE,MAAM,CAAC,CAUjE,CAAC;AAEF,iFAAiF;AACjF,wBAAgB,sBAAsB,CAAC,MAAM,EAAE;IAAE,KAAK,EAAE,OAAO,CAAA;CAAE,GAAG,KAAK,CAMxE;AAED;;;GAGG;AACH,wBAAgB,iBAAiB,CAAC,MAAM,EAAE;IAAE,KAAK,EAAE,OAAO,CAAA;CAAE,GAAG,MAAM,CAepE;AAID;;;;;;;GAOG;AACH,wBAAgB,mBAAmB,CAAC,MAAM,EAAE;IAC1C,KAAK,EAAE,OAAO,CAAC;IACf,KAAK,EAAE,WAAW,CAAC,MAAM,EAAE,MAAM,CAAC,CAAC;CACpC,GAAG,MAAM,CAWT;AAED;;;;GAIG;AACH,wBAAgB,wBAAwB,CAAC,MAAM,EAAE;IAAE,KAAK,EAAE,OAAO,CAAA;CAAE,GAAG,MAAM,GAAG,IAAI,CAOlF;AAID;;;;GAIG;AACH,wBAAgB,gBAAgB,CAAC,MAAM,EAAE;IAAE,KAAK,EAAE,OAAO,CAAA;CAAE,GAAG,MAAM,GAAG,SAAS,CAuB/E;AAID;;;GAGG;AACH,wBAAgB,mBAAmB,CAAC,MAAM,EAAE;IAC1C,KAAK,EAAE,MAAM,CAAC;IACd,MAAM,EAAE,MAAM,CAAC;IACf,QAAQ,EAAE,MAAM,CAAC;CAClB,GAAG,MAAM,CAET;AAED,2EAA2E;AAC3E,MAAM,MAAM,eAAe,GAAG;IAC5B,QAAQ,CAAC,MAAM,EAAE,MAAM,CAAC;IACxB,QAAQ,CAAC,QAAQ,EAAE,MAAM,CAAC;IAC1B,QAAQ,CAAC,MAAM,EAAE,SAAS,MAAM,EAAE,CAAC;CACpC,CAAC;AAKF,sEAAsE;AACtE,MAAM,MAAM,gBAAgB,GAAG;IAC7B,QAAQ,CAAC,IAAI,EAAE,MAAM,CAAC;IACtB,QAAQ,CAAC,UAAU,EAAE,MAAM,CAAC;CAC7B,CAAC;AAEF;;;;;GAKG;AACH,wBAAgB,sBAAsB,CAAC,MAAM,EAAE;IAAE,QAAQ,EAAE,MAAM,CAAA;CAAE,GAAG,gBAAgB,EAAE,CAuBvF;AAED;;;;GAIG;AACH,wBAAgB,qBAAqB,CAAC,MAAM,EAAE;IAAE,QAAQ,EAAE,MAAM,CAAA;CAAE,GAAG,eAAe,EAAE,CAYrF"}