@vibeorm/adapter-bun 2.1.0 → 2.1.1

package/README.md

@@ -42,6 +42,27 @@ await db.$disconnect();
 
 `Date` parameters are spelled as UTC ISO text on both paths: bun:sql's own serializer for a `date`-typed parameter is `Date#toString()`, which the server rejects in every host time zone. Zone-less columns (`@db.Timestamp(n)`, `@db.Date`) therefore hold the UTC wall-clock on write — the contract shared with node-postgres, PGlite and Prisma. On read, bun:sql is UTC from **Bun 1.4.1**; earlier Bun versions parse zone-less timestamp text as host-local time (1.3.x: scalars on parameterless statements and every array element; 1.4.0: array elements), and bun:sql has no per-query parser hook the adapter could use to correct it. On Bun < 1.4.1 keep the process on `TZ=UTC` when the schema has zone-less columns, or upgrade (`docs/dialect-notes.md` "DateTime without time zone on postgres").
 
+## Raw parameters
+
+bun:sql types every parameter by the OID the server infers for its slot, and for a `json`/`jsonb` slot it JSON-encodes **whatever JavaScript value is bound** — an object becomes the document, and a string that already holds JSON text becomes a JSON *string* (double-encoded). node-postgres sends a string as text regardless of the slot, so the same raw statement stores the document there. Measured on Bun 1.4.3 / PostgreSQL 18 (`tests/raw-jsonb.live.test.ts` here and in `@vibeorm/adapter-pg`):
+
+| `$executeRaw` … `VALUES (${value}::jsonb)` | adapter-bun stores | adapter-pg stores |
+|---|---|---|
+| `{ a: 1 }` (JS object) | `object` | `object` |
+| `'{"a":1}'` (pre-encoded text) | **`string`** | `object` |
+| `'{"a":1}'` through `${value}::text::jsonb` | `object` | `object` |
+
+Bind the object itself, or spell the slot `::text::jsonb` when you bind pre-encoded text — that is the portable form, and it is what the ORM path renders for every `Json` field (`jsonParamCast` in the postgres dialect), which is why `Json` columns behave identically on both adapters. A JS **array** on the raw path is rendered as a PostgreSQL array literal (for `= ANY($1)`), so a JSON array bound into a json column from raw SQL needs `JSON.stringify` plus the `::text::jsonb` spelling.
+
+## Session lifetime on `$disconnect()`
+
+`disconnect()` rolls back an open raw transaction, releases its reserved connection and closes the pool with bun:sql's `close()`, which waits for in-flight statements to finish. The promise resolves once the client sockets are shut; PostgreSQL removes the sessions from `pg_stat_activity` a few milliseconds later (0–5 ms measured on Bun 1.4.3, the same window node-postgres' `pool.end()` has). `tests/session-lifetime.live.test.ts` pins that every session the adapter can hold — pool, options-transaction connection, raw-transaction session — is gone after `disconnect()`, with a bounded poll.
+
+Two things that are NOT the adapter's doing but look like a leak:
+
+- A `DROP DATABASE` issued from another connection in the same millisecond can still see a closing session and refuse with SQLSTATE 55006. Poll `pg_stat_activity` for your `application_name` first, or use `DROP DATABASE … WITH (FORCE)` (PostgreSQL 13+).
+- bun:sql never closes idle connections by default (`idleTimeout: 0`), whereas node-postgres reaps an idle client after 10 s. An adapter you never `disconnect()` therefore holds its sessions for the life of the process on bun:sql, where node-postgres would have quietly dropped them.
+
 ## Runtime support
 
 | Runtime | Supported |

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@vibeorm/adapter-bun",
-  "version": "2.1.0",
+  "version": "2.1.1",
   "description": "bun:sql (Postgres) adapter for VibeORM v2",
   "keywords": [
     "orm",
@@ -41,9 +41,9 @@
     "bun": ">=1.2.0"
   },
   "dependencies": {
-    "@vibeorm/runtime": "2.1.0",
-    "@vibeorm/schema": "2.1.0",
-    "@vibeorm/sql": "2.1.0"
+    "@vibeorm/runtime": "2.2.0",
+    "@vibeorm/schema": "2.1.1",
+    "@vibeorm/sql": "2.1.1"
   },
   "publishConfig": {
     "access": "public"