drizzle: SQLiteInsertBase methods (_prepare, prepare, execute, returning, etc) return undefined when accessed via Any-typed receiver

[proggeramlug]

Summary

After v0.5.755 (cross-module ctor field-init persistence), drizzle's full insert chain still hits TypeError: Cannot read properties of undefined (reading 'run'). Bisecting reveals: (ins as any)._prepare is undefined even though _prepare is a regular method declaration on SQLiteInsertBase (line 140 of drizzle-orm/sqlite-core/query-builders/insert.js).

Repro

import { sqliteTable, integer, text } from "drizzle-orm/sqlite-core";
import Database from "better-sqlite3";
import { drizzle } from "drizzle-orm/better-sqlite3";

const sqlite = new Database(":memory:");
const db = drizzle(sqlite);
const users = sqliteTable("users", { id: integer("id").primaryKey(), name: text("name").notNull() });
sqlite.exec(`CREATE TABLE users (id INTEGER PRIMARY KEY, name TEXT NOT NULL)`);

const ins = db.insert(users).values([{ id: 1, name: "alice" }]);

console.log("ins.constructor[entityKind]:", (ins as any).constructor[Symbol.for("drizzle:entityKind")]);
//   → "SQLiteInsert" ✓

console.log("typeof ins.run:", typeof (ins as any).run);          // function ✓
console.log("typeof ins._prepare:", typeof (ins as any)._prepare); // undefined ✗ (Node: function)
console.log("typeof ins.prepare:", typeof (ins as any).prepare);   // undefined ✗
console.log("typeof ins.execute:", typeof (ins as any).execute);   // undefined ✗
console.log("typeof ins.returning:", typeof (ins as any).returning); // undefined ✗

ins.run();  // TypeError: Cannot read properties of undefined (reading 'run')
            // ins.run is `(p) => this._prepare().run(p)`; _prepare returns undefined

Pattern

The class SQLiteInsertBase mixes:

• Arrow-function fields (run = (p) => ..., all, get, values) — VISIBLE in Perry
• Method declarations (_prepare(), prepare(), returning(), execute(), getSQL(), etc.) — UNDEFINED in Perry

Both should work via the vtable. Perry's PIC / property dispatch only finds the arrow-function fields (instance slots), not the prototype methods.

Bisection state

• v0.5.755 makes sess.client/dialect/logger correctly set after super()
• Direct call also fails: (ins as any)._prepare() returns undefined (not a "method not found" throw — just undefined return)
• Isolated repros with the same shape (extends from another module, static [entityKind], mixed methods+fields, computed-key dispatch in body) all WORK in tests/release/packages/drizzle-sqlite or in /tmp/method_dispatch/. Something specific to drizzle's actual class registration (~100+ classes with shared inheritance) breaks this.

Acceptance

tests/release/packages/drizzle-sqlite/entry.ts produces output byte-identical to expected.txt.

Refs

• Compile drizzle-orm end-to-end via perry.compilePackages #420 / Function-static properties assigned via IIFE pattern (((fn) => { fn.method = ...; })(fn)) don't work — both same-module and cross-module #618 — drizzle Table chain
• v0.5.745 / v0.5.746 / v0.5.748 / v0.5.749 / v0.5.750 / v0.5.751 / v0.5.752 / v0.5.753 / v0.5.754 / v0.5.755 (cumulative drizzle is() chain fixes)

[proggeramlug]

Partial fix landed in v0.5.764: the originally-tracked methods (_prepare/prepare/execute/returning) all return functions on Any-typed receivers (v0.5.756 bound-method fallback). better-sqlite3's missing stmt.raw() method — surfaced when drizzle's chain advanced past _prepare to PreparedQuery.values() — is also wired end-to-end now (perry-stdlib + perry-ext-better-sqlite3 + dispatch arm + raw-mode .all/.get). Direct-call shape (stmt as any).raw().all() works. Drizzle's full chain still fails because of #645 (dispatch tower returns raw int handle from class-method-internal native calls instead of NaN-boxing as POINTER) — filed as separate followup since the root cause is the codegen dispatch tower path, not sqlite-specific.

[proggeramlug]

State update against current main (v0.5.795).

The drizzle-sqlite fixture (tests/release/packages/drizzle-sqlite/entry.ts) now compiles cleanly and reaches further into the chain than the originally-tracked symptom — _prepare / prepare / execute / returning are all callable on Any-typed receivers (v0.5.756 bound-method fallback + v0.5.795 cjs-wrap class hoist for the SQLiteInsertBase shape), and sqliteTable(...) + db.insert(users).values([...]) succeed in setting up the query. The current blocker has shifted: .run() returns NaN (better-sqlite3 stmt.raw() wired via v0.5.764 returns the wrong wrapper shape downstream), and the subsequent db.select().from(users) throws Cannot read properties of undefined (reading 'tableName').

The tableName failure is in drizzle-orm's select query builder — it reads <something>.tableName where the receiver came through a cross-module class-instance handoff. There are 30+ tableName reads across relations.cjs / utils.cjs / casing.cjs / column.cjs / column-builder.cjs — bisecting which one trips needs a focused diagnostic session.

This is incremental multi-session work, not a single-fix issue. Each fix exposes the next blocker. Closing out the loop iteration on this one without a partial commit — the current main is the best state. Tracking the next focused fix in a separate session.

[proggeramlug]

Closing — acceptance criteria met on current main (v0.5.891, bb7ab69).

tests/release/packages/drizzle-sqlite/entry.ts now produces byte-identical output to expected.txt:

$ bash tests/release/packages/drizzle-sqlite/fixture.sh
[perry compile] entry.ts
  [./out] (timeout=60s)
  [diff] expected.txt vs perry-out.txt
PASS drizzle-sqlite

The remaining blockers from the v0.5.795 status update (.run() returning NaN, and db.select().from(users) throwing on a downstream tableName read) were closed out incrementally across the ~96 patch versions since.