neoorm 0.7.4 → 0.8.0

package/docs/queries.md

@@ -19,14 +19,36 @@ const users = await db.users.findMany({
   skip: 40,
 });
 
+// First match after skip, or with DISTINCT ON (null if not found)
+await db.users.findFirst({ orderBy: { email: "asc" }, skip: 1 });
+await db.users.findFirst({
+  distinct: ["email"],
+  orderBy: { email: "asc" },
+});
+
 // Unique constraint lookup
 const user = await db.users.findUnique({ where: { slug: "hello" } });
 ```
 
+Unique `where` (`findUnique`, `upsert`, `findOrCreate`, singular `update`/`delete`) is scalar equality per unique field — `{ email: "a@b.com" }`, not a filter. `{ equals: value }` is accepted and unwrapped to the scalar. Other operators (`contains`, `in`, `mode: "insensitive"`) throw `unique_where_invalid`.
+
 ## Create
 
 ```ts
-const user = await db.users.create({ data: { email: "a@b.com" } });
+const created = await db.users.create({ data: { email: "a@b.com" } });
+created.id; // primary key is always returned
+
+// Pass returnCreated: true to get the full row (defaults, timestamps, …)
+const user = await db.users.create({
+  data: { email: "a@b.com" },
+  returnCreated: true,
+});
+
+// `with` also returns the full row (plus relations)
+const post = await db.posts.create({
+  data: { title: "Hello", body: "…", authorId: user.id },
+  with: { author: true },
+});
 
 // Bulk insert (returns count)
 const count = await db.users.createMany({
@@ -47,13 +69,24 @@ const users = await db.users.createManyAndReturn({
 });
 ```
 
+Unknown keys in `data` fail at compile time (`unknown_column`), same as `where`.
+
 ## Update
 
+Singular `update` requires a unique `where` (primary key, `@unique` column, or composite unique index), same as `findUnique`. Use `updateMany` when the filter can match multiple rows.
+
 ```ts
-// Single record
+// Returns {} on success, null if no row matched
+const updated = await db.users.update({
+  where: { id: userId },
+  data: { email: "new@b.com" },
+});
+
+// Pass returnUpdated: true to get the updated row back
 const user = await db.users.update({
   where: { id: userId },
   data: { email: "new@b.com" },
+  returnUpdated: true,
 });
 
 // By ID (scalar PK — string; composite PK — object)
@@ -73,6 +106,12 @@ const updated = await db.users.updateManyAndReturn({
   where: { email: { contains: "@old" } },
   data: { status: "archived" },
 });
+
+const post = await db.posts.update({
+  where: { id: postId },
+  data: { title: "New" },
+  with: { author: true }, // full row plus relations; no returnUpdated needed
+});
 ```
 
 Numeric columns (`int`, `serial`, `decimal`, `bigint`) also accept `{ increment }`, `{ decrement }`, `{ multiply }`, and `{ set }`. These compile to `col = col ±/* $n` so concurrent updates do not clobber each other. `{ set: value }` is the same assignment as a plain value. `NULL + 1` stays SQL NULL.
@@ -91,6 +130,8 @@ await db.posts.updateMany({
 
 ## Delete
 
+Singular `delete` requires a unique `where`. Use `deleteMany` for bulk deletes.
+
 ```ts
 // Returns {} on success, null if no row matched
 await db.users.delete({ where: { id: userId } });
@@ -101,6 +142,12 @@ const deleted = await db.users.delete({
   returnDeleted: true,
 });
 
+// `with` also returns the full row (plus relations), even without returnDeleted
+const post = await db.posts.delete({
+  where: { id: postId },
+  with: { author: true },
+});
+
 // Scalar PK — pass a string
 await db.users.deleteById(userId);
 
@@ -132,6 +179,10 @@ Atomically insert a row or return an existing one when a unique constraint match
 
 `where` must identify a unique constraint (same rules as `findUnique` and `upsert`).
 
+Postgres issues `INSERT … ON CONFLICT DO UPDATE` with a no-op assignment so `RETURNING` always includes the row — including when a concurrent session already inserted it. `created` is `(xmax = 0)` (inserted vs existing). A no-op update can fire `UPDATE` triggers; column values are not changed.
+
+Under `SERIALIZABLE` (and sometimes `REPEATABLE READ`), a concurrent insert can still abort the transaction with a serialization failure. Retry the whole `$transaction`. SQLite uses find-then-insert and retries the find after a unique violation.
+
 ```ts
 const { record, created } = await db.tags.findOrCreate({
   where: { slug: "orm" },
@@ -158,22 +209,31 @@ await db.posts.findFirst({
 });
 ```
 
+Unknown column names and operators fail at compile time (`unknown_column`, with “did you mean” hints). JSON columns may still use a plain object as equality (`{ metadata: { featured: true } }`).
+
 | Type | Operators |
 |------|-----------|
 | String | `equals`, `contains`, `startsWith`, `endsWith`, `search`, `in`, `notIn`, `mode` |
 | Numeric / Date | `equals`, `gt`, `gte`, `lt`, `lte`, `in`, `notIn` |
 | JSON | `jsonContains`, `hasKey`, `hasAnyKeys`, `hasAllKeys`, `path` |
+| PostGIS (`geometry`, `geography`, `point`) | `intersects`, `within`, `dWithin` |
 | All nullable | `isNull`, `isNotNull` |
 
-`contains`, `startsWith`, and `endsWith` compile to `LIKE`. Pass sibling `mode: "insensitive"` for case-folding (`ILIKE` on Postgres, `LOWER(col) LIKE LOWER($n)` on SQLite). SQLite `LIKE` is ASCII case-insensitive even in default mode.
+`contains`, `startsWith`, `endsWith`, and `equals` compile to `LIKE` / `=`. Pass sibling `mode: "insensitive"` for case-folding (`ILIKE` on Postgres, `LOWER(col) LIKE LOWER($n)` on SQLite). SQLite `LIKE` is ASCII case-insensitive even in default mode.
 
 `search` is POSIX regex (`~`, or `~*` with `mode: "insensitive"`). It is PostgreSQL-only; SQLite throws.
 
+JSON operators on PostgreSQL use `@>`, `?`, and `#>` / `#>>`. On SQLite they compile to `json_patch` (object containment), `json_each` (key existence), and `json_extract` (path).
+
 ```ts
 await db.posts.findMany({
   where: { title: { contains: "orm", mode: "insensitive" } },
 });
 
+await db.users.findMany({
+  where: { email: { equals: "Ada@Example.com", mode: "insensitive" } },
+});
+
 await db.posts.findMany({
   where: { title: { search: "^Neo", mode: "insensitive" } },
 });
@@ -194,6 +254,8 @@ await db.users.findMany({
 });
 ```
 
+Empty `OR: []` matches no rows. Empty `AND: []` matches every row. Empty `in: []` is false; `{ OR: [{ id: { in: [] } }, { name: "Ada" }] }` still matches the other branch.
+
 ### Relation filters
 
 ```ts
@@ -218,7 +280,7 @@ await db.posts.findMany({
 | `authorId: "user_1"` | Filter by FK column value |
 | `author: { email: "a@b.c" }` | Filter by related record (to-one) |
 | `posts: { some: { ... } }` | At least one related record matches (to-many) |
-| `posts: { every: { ... } }` | All related records match (to-many) |
+| `posts: { every: { ... } }` | All related records match (to-many). Compiled as `NOT EXISTS` of related rows that fail the nested filter. |
 | `posts: { none: { ... } }` | No related records match (to-many) |
 
 Relation filters compile to SQL `EXISTS` subqueries, so they work with `findMany`, `count`, `updateMany`, and `deleteMany` without duplicate rows.
@@ -226,7 +288,7 @@ Relation filters compile to SQL `EXISTS` subqueries, so they work with `findMany
 ### JSON and decimal filters
 
 ```ts
-// jsonb — partial / subset match (@> containment)
+// jsonb — partial / subset match (`@>` on PostgreSQL, `json_patch` on SQLite)
 await db.posts.findMany({
   where: { metadata: { jsonContains: { featured: true } } },
 });
@@ -250,7 +312,7 @@ await db.posts.findMany({
 
 ### `distinct`
 
-PostgreSQL `DISTINCT ON` — `orderBy` must lead with the same columns:
+PostgreSQL `DISTINCT ON` — `orderBy` must lead with the same columns (key order is the ORDER BY prefix):
 
 ```ts
 await db.users.findMany({
@@ -270,9 +332,10 @@ Relations are eagerly loaded in `findMany`, `findFirst`, and `findById` via the
 NeoORM uses a relation-loading planner that picks the fewest round-trips per `with` tree:
 
 - **LEFT JOIN** — to-one relations where the parent table owns the foreign key are resolved in the main query. No additional round-trips.
+- **JOIN + `json_agg`** — a single inverse has-many include may use one collection `LEFT JOIN` with `GROUP BY`. A second collection is a correlated subquery so sizes N and M do not become N×M rows.
 - **Correlated `json_agg` subquery** — inverse has-many relations (and simple linear nested chains) are embedded in the main `SELECT` as correlated subqueries. Multiple top-level relations can be inlined in the same query alongside JOINs.
-- **Inline `COUNT` subquery** — simple `_count` on has-many relations is embedded in the main `SELECT`.
-- **Batch query** — many-to-many, nested `with` on to-one, sibling-heavy trees, and other complex shapes fall back to batched `WHERE IN (...)` queries (one per relation level). Sibling batch queries at the same level run in parallel.
+- **Inline `COUNT` subquery** — simple `_count` on has-many relations is embedded in the main `SELECT`. At most one `_count` collection uses a `LEFT JOIN`; additional counts are correlated `COUNT(*)` subqueries.
+- **Batch query** — many-to-many, nested `with` on to-one, sibling-heavy trees, and other complex shapes fall back to batched `WHERE IN (...)` queries (one per relation level). Sibling batch queries at the same level run in parallel. Nested `take`/`skip` on those batches apply **per parent** (window ranking), not to the whole `IN` list.
 
 Typical query counts:
 
@@ -395,7 +458,8 @@ for (;;) {
 ```
 
 - `orderBy` is required; scalar `id` is appended automatically when omitted.
-- `take` is the page size; `hasMore` / `hasPrevious` use a `take + 1` probe row (plus whether `after` / `before` was passed).
+- `select`, `omit`, and `includeHidden` work like `findMany`. Cursor fields used by `orderBy` stay in the SQL (and in `nextCursor` / `prevCursor`) even when omitted from `items`.
+- `take` is the page size; `hasMore` / `hasPrevious` use a `take + 1` probe in the query direction. A `before` page also probes once forward so `hasMore` is not assumed true. After an `after` page, `hasPrevious` is true because `after` was passed.
 - `after` is a typed cursor (`nextCursor` from the previous page). `before` walks the other way (`prevCursor`).
 - `after` and `before` can be combined as exclusive window bounds; pass both on every windowed call.
 - For HTTP APIs, encode cursors with `encodeCursor` / `decodeCursor` from `neoorm`.
@@ -441,7 +505,7 @@ const stats = await db.posts.aggregate({
 
 `_count: true` is still `COUNT(*)` and returns `_count: number`. A field map uses `COUNT(col)` (nulls are skipped) — not `DISTINCT`.
 
-Single-table grouped stats use `groupBy()`. Cross-table dashboards still use `db.sql` or `sqlBuilder`.
+Single-table grouped stats use `groupBy()`. Cross-table dashboards still use `db.sql` (same compiler as `neoorm/sql`) or `sqlBuilder` composed into `db.sql`.
 
 ### `groupBy()`
 
@@ -478,3 +542,38 @@ const taken = await db.users.exists({ where: { email: "a@b.com" } });
 `count()` returns a number unless `select` is set. `distinct` is `COUNT(DISTINCT col)` on one column and cannot be combined with `select`. Field `select` / `_count` maps are non-null `COUNT(col)`, not distinct.
 
 `exists()` runs `SELECT 1 … LIMIT 1` and returns a boolean. Use `count()` when you need the actual number of matches.
+
+## Raw SQL
+
+`db.sql` and `import { sql } from "neoorm/sql"` share one compiler. Interpolate values, `sqlId("table")`, nested `sql\`...\`` fragments, or `sqlBuilder.compile()`. `sqlBuilder` itself has no WHERE, LIMIT, or params — add those in the `db.sql` tag.
+
+```ts
+import { sql, sqlBuilder, sqlId } from "neoorm/sql";
+
+const ident = sqlId("users");
+const filter = sql`email = ${"a@b.com"}`;
+const rows = await db.sql`SELECT * FROM ${ident} WHERE ${filter}`;
+
+const grouped = sqlBuilder
+  .selectFrom("users")
+  .select(["id", "email"])
+  .groupBy("id", "email")
+  .compile();
+await db.sql`${grouped} LIMIT ${10}`;
+```
+
+`db.execute({ text, params })` runs already-compiled SQL. Raw SQL is not rewritten for tenant `schema` — qualify identifiers yourself.
+
+## Logging SQL
+
+Pass `beforeQuery` / `afterQuery` when creating the client. They run for repository methods and `db.sql` / `db.execute`, including queries inside `$transaction`. BEGIN/COMMIT/SAVEPOINT are not included.
+
+```ts
+const db = createNeoOrmClient(manifest, {
+  afterQuery: ({ sql, params, durationMs, error }) => {
+    if (error || durationMs > 100) {
+      console.warn({ sql, params, durationMs, error });
+    }
+  },
+});
+```

package/docs/relations.md

@@ -1,6 +1,6 @@
 # Relation writes
 
-`create` and `update` accept nested relation writes alongside scalar fields. Relation-only updates are supported (no scalar `SET` required).
+`create` and `update` accept nested relation writes alongside scalar fields. Relation-only updates are supported (no scalar `SET` required). Nested to-one `create` on `update` (and `create`) runs in the same transaction as the parent row so a failed parent write does not leave an orphan.
 
 ## Supported operations
 
@@ -10,6 +10,10 @@
 | **One-to-many** (inverse) | `create`, `connect`, `disconnect`, `set`, `delete` |
 | **Many-to-many** | `connect`, `connectOrCreate`, `disconnect`, `set`, `delete` |
 
+`connect`, `set`, `disconnect`, and `delete` identify related rows by the **target table's scalar primary key** (`{ id: ... }` when the PK is `id`, `{ userId: ... }` when it is `userId`). Composite-PK connect is not supported.
+
+A relation field must be a **pure write bag**: every key is one of those operations. Mixing a write op with extra fields (`{ create: { name: "A" }, foo: 1 }`), passing a scalar, or passing `{}` throws `invalid_nested_write` — the parent row is not written.
+
 ## Examples
 
 ### To-one on update

package/docs/schema.md

@@ -1,6 +1,6 @@
 # Schema DSL
 
-NeoOrm **0.6** uses accessor-based identity: schema keys, `fk("users")`, `many("tags")`, and `through: "postTags"` all refer to **accessors**, not raw SQL names. `schemaToManifest` resolves accessors to SQL before migrations and the typed client are generated.
+NeoOrm **0.8.0** uses accessor-based identity: schema keys, `fk("users")`, `many("tags")`, and `through: "postTags"` all refer to **accessors**, not raw SQL names. `schemaToManifest` resolves accessors to SQL before migrations and the typed client are generated.
 
 ## Tables and accessors
 
@@ -26,6 +26,8 @@ export const schema = defineSchema({
 - `table({ columns, extras? })` — SQL name is filled in from the accessor (`users` → `"users"`).
 - `table("sql_name", { columns }, extras?)` — override the SQL name (`postTags` → `"post_tags"`).
 
+Generated row types are the English singular of the accessor: `users` → `User`, `status` → `Status` (not `Statu`).
+
 Column field names use camelCase in TypeScript. By default SQL column names are snake_case (`createdAt` → `created_at`). See [column naming](#column-naming-strategy).
 
 ## Column types
@@ -41,7 +43,7 @@ Column field names use camelCase in TypeScript. By default SQL column names are
 | `bool()` | `BOOLEAN` | `boolean \| null` | |
 | `int()` | `INTEGER` | `number \| null` | |
 | `bigint()` | `BIGINT` | `bigint \| null` | Maps to `TEXT` on SQLite |
-| `timestamp()` | `TIMESTAMPTZ` | `Date \| null` | `.defaultNow()` / `.updatedAt()` on timestamp builders only |
+| `timestamp()` | `TIMESTAMPTZ` | `Date \| null` | `.defaultNow()` / `.updatedAt()` on timestamp builders only. Maps to `TEXT` on SQLite |
 | `json()` / `jsonb()` | `JSON` / `JSONB` | `unknown \| null` | Generic: `jsonb<MyType>()` |
 | `decimal()` / `numeric()` | `NUMERIC` | `string \| null` | Use strings to avoid float loss |
 | `enumType(["a", "b"])` | mode-dependent | union literals | See [Enum columns](#enum-columns) |
@@ -119,6 +121,8 @@ postTags: table("post_tags", {
 }),
 ```
 
+Multiple `.primary()` columns infer a composite key. `primaryKey(t.colA, t.colB)` in extras is optional when you want to name the key without marking every column.
+
 ### Self-relations
 
 ```ts
@@ -168,15 +172,18 @@ posts: table(
 ),
 ```
 
-Helpers: `unique(...cols)`, `index(...cols)`, `primaryKey(...cols)`.
+Helpers: `unique(...cols)`, `index(...cols)`, `primaryKey(...cols)`. `unique()` and `index()` both support `.where()` for partial indexes.
 
 ### Partial indexes
 
 ```ts
-(t) => [index(t.title).where({ published: true })],
+(t) => [
+  index(t.title).where({ published: true }),
+  unique(t.email).where({ deleted: false }),
+],
 ```
 
-Equality map of column refs → values; compiled to `WHERE "published" = true` (or `= 1` on SQLite).
+Equality map of column refs → values; compiled to `WHERE "published" = true` (or `= 1` on SQLite). Partial uniques emit as `CREATE UNIQUE INDEX ... WHERE ...`, not table-level `UNIQUE (...)`. They are not usable as `findUnique` / `upsert` targets.
 
 ## Many-to-many
 

package/docs/sqlite.md

@@ -4,13 +4,13 @@ SQLite is a first-class dialect for local development, testing, and single-file
 
 ## Requirements
 
-No SQLite package is required — NeoOrm uses the driver bundled with your runtime:
+NeoOrm requires **Node.js 22.5+** or **Bun**. No SQLite package is required — auto-open uses the driver bundled with your runtime:
 
 | Runtime | Driver |
 |---------|--------|
 | Node.js 22.5+ | built-in `node:sqlite` (`DatabaseSync`) |
 | Bun | `bun:sqlite` |
-| Anything else | pass your own `db` instance (see [Custom driver](#custom-driver)) |
+| Custom | pass your own `db` instance (see [Custom driver](#custom-driver)) |
 
 If none is available, creating a client throws: `No SQLite driver available. Provide a db instance, or run on Bun or Node.js 22.5+`.
 
@@ -48,19 +48,33 @@ const db = createNeoOrmClient(manifest, {
 
 Use `databasePath: ":memory:"` for an in-memory database (one connection, no persistence).
 
+Wrapping a connection sets `PRAGMA foreign_keys = ON`, `busy_timeout = 5000`, and `journal_mode = WAL` (WAL is a no-op for `:memory:`). Opt out per client:
+
+```ts
+const db = createNeoOrmClient(manifest, {
+  provider: "sqlite",
+  databasePath: "./dev.db",
+  sqlite: { wal: false, busyTimeout: false },
+});
+```
+
+`busyTimeout` can also be a millisecond wait (`sqlite: { busyTimeout: 10_000 }`).
+
 ### Custom driver
 
 Pass any object implementing `prepare(sql)`, `exec(sql)`, and `close()` — the `node:sqlite` and `bun:sqlite` APIs both match. Useful for sandboxed runtimes or existing database handles:
 
 ```ts
 import { DatabaseSync } from "node:sqlite";
-import { createNeoOrmClient } from "neoorm";
+import { createNeoOrmClientFromSqlite } from "neoorm";
 import { manifest } from "./neoorm/manifest.js";
 
 const database = new DatabaseSync("./dev.db");
-const db = createNeoOrmClient(manifest, { db: database });
+const db = createNeoOrmClientFromSqlite(manifest, database);
 ```
 
+`$disconnect()` does not close the handle — call `database.close()` yourself. `createNeoOrmClient(manifest, { db: database })` is the same ownership model.
+
 ## CLI
 
 The full CLI works against SQLite:
@@ -73,7 +87,7 @@ bunx neoorm migrate status
 bunx neoorm migrate reset --force
 ```
 
-- The migration ledger table is `_neoorm_migrations` (`id INTEGER PRIMARY KEY AUTOINCREMENT`).
+- The migration ledger table is `_neoorm_migrations` (`id INTEGER PRIMARY KEY AUTOINCREMENT`, `name`, `checksum`, `applied_at`). `migrate deploy` wraps the run in `BEGIN IMMEDIATE` and refuses an edited `migration.sql` whose checksum no longer matches the ledger.
 - `migrate reset` drops all non-`sqlite_` tables (there is no schema concept).
 - `db pull` introspects `sqlite_master` back into a schema file.
 
@@ -86,11 +100,11 @@ bunx neoorm migrate reset --force
 | `bigint` | `TEXT` |
 | `serial().primary()` | `INTEGER PRIMARY KEY AUTOINCREMENT` |
 | `bool` | `BOOLEAN` (stored as 0/1) |
-| `timestamp` | `TIMESTAMPTZ` (stored as ISO-8601 text) |
+| `timestamp` | `TEXT` (ISO-8601) |
 | `bytea` | `BLOB` |
 | `fk` | the target column's type (default `TEXT`) |
 
-`defaultNow()` compiles to `CURRENT_TIMESTAMP`. Structural table changes that SQLite cannot do in place (column type changes, FK changes) are applied via a table-rebuild strategy: create `__neoorm_<table>_new`, copy rows, drop the old table, rename.
+`defaultNow()` compiles to `CURRENT_TIMESTAMP`. Structural table changes that SQLite cannot do in place (column type changes, FK changes, nullability) are applied via a table-rebuild strategy: `PRAGMA foreign_keys = OFF`, then in one transaction create `__neoorm_<table>_new`, copy rows, drop the old table, rename, and `PRAGMA foreign_keys = ON`. Foreign keys must be disabled *before* `BEGIN` — SQLite ignores that pragma inside a transaction. The client always enables `foreign_keys` at connect time, so inbound FKs (e.g. `posts.user_id` → `users`) would otherwise block `DROP TABLE` of the parent.
 
 ## Differences from PostgreSQL
 
@@ -99,7 +113,7 @@ bunx neoorm migrate reset --force
 | `distinct` (`DISTINCT ON`) | supported | throws `distinct is not supported on SQLite` |
 | `datasource.schema` | multi-schema | not applicable |
 | `enum: "native"` | `CREATE TYPE ... AS ENUM` | not applicable (TEXT + CHECK) |
-| transaction options (`readOnly`, `isolationLevel`) | full | outer `BEGIN` only; nested transactions use savepoints |
-| JSON operators | `@>`, `?`, path ops | implemented with `json_each` / `json_object` |
+| transaction options (`readOnly`, `isolationLevel`) | `BEGIN READ ONLY` / `ISOLATION LEVEL` | `readOnly` → `PRAGMA query_only`; `RepeatableRead`/`Serializable` → `BEGIN IMMEDIATE`; other isolation → `BEGIN` |
+| JSON operators | `@>`, `?`, `#>` | `json_patch` / `json_each` / `json_extract` |
 
-Everything else — relations, nested writes, cursor pagination, aggregates, `groupBy`, upsert, `findOrCreate`, savepoint-based nested transactions — behaves identically.
+Everything else — relations, nested writes, cursor pagination, aggregates, `groupBy`, upsert, `findOrCreate`, savepoint-based nested transactions — behaves identically.

package/docs/transactions.md

@@ -49,6 +49,17 @@ await db.$transaction(async (tx) => {
 });
 ```
 
-Nested `create` calls inside a transaction do not start a separate transaction. `readOnly` and `isolationLevel` apply only to the outermost `BEGIN`.
+Nested `$transaction` uses a savepoint on the same connection, not a new `BEGIN`. `readOnly` and `isolationLevel` are only valid on the outermost `$transaction`; passing them on a nested call throws.
 
-On SQLite, nested transactions use `SAVEPOINT`/`RELEASE`/`ROLLBACK TO SAVEPOINT`; `readOnly` and `isolationLevel` are rejected on nested transactions (mapped to `BEGIN`/`BEGIN IMMEDIATE`/`BEGIN DEFERRED` on the outer transaction).
+### SQLite
+
+SQLite has no `BEGIN READ ONLY` and no SQL isolation levels. Outer `$transaction` options map as follows:
+
+| Option | SQLite |
+|--------|--------|
+| `readOnly: true` | `PRAGMA query_only = ON` for the duration of the transaction (writes fail) |
+| `isolationLevel: "RepeatableRead"` or `"Serializable"` | `BEGIN IMMEDIATE` (reserved lock before the first statement) |
+| `isolationLevel: "ReadUncommitted"` or `"ReadCommitted"` | `BEGIN` (deferred; default) |
+| nested `$transaction` | `SAVEPOINT` — `readOnly` / `isolationLevel` are rejected |
+
+After the transaction commits or rolls back, `query_only` is turned off so later writes succeed.

package/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "neoorm",
-	"version": "0.7.4",
+	"version": "0.8.0",
 	"description": "TypeScript-first PostgreSQL and SQLite ORM with schema DSL, codegen, and typed relations",
 	"license": "MIT",
 	"repository": {
@@ -73,12 +73,14 @@
 		"database"
 	],
 	"engines": {
-		"node": ">=20"
+		"node": ">=22.5.0"
 	},
 	"scripts": {
 		"build": "bunx tsc -p tsconfig.build.json",
 		"typecheck": "bunx tsc -p tsconfig.json --noEmit",
 		"dev": "bunx tsc -w -p tsconfig.build.json",
+		"lint": "biome check .",
+		"format": "biome format --write .",
 		"test": "bunx vitest run",
 		"prepublishOnly": "bun run build && bun run test"
 	},