@drzl/analyzer 1.16.0 → 1.17.1

package/dist/index.cjs

@@ -70,6 +70,12 @@ var TUPLE_CLASS_SHAPES = {
   PgLineTuple: { kind: "tuple", length: 3 }
 };
 var V1_ONLY_ENTITY_KINDS = /^(?:MsSql|Cockroach)/;
+var BYTE_STRING_CLASSES = /* @__PURE__ */ new Set([
+  "MySqlBinary",
+  "MySqlVarBinary",
+  "SingleStoreBinary",
+  "SingleStoreVarBinary"
+]);
 function describeV1Column(column) {
   const codec = column?.codec;
   const dataType = column?.dataType;
@@ -170,17 +176,20 @@ function describeV1Column(column) {
       out.tsType = "string";
       out.dbType = semantic.toUpperCase();
       break;
-    case "binary":
+    case "binary": {
+      const entity = String(column?.constructor?.[/* @__PURE__ */ Symbol.for("drizzle:entityKind")] ?? "");
+      const bytes = entity.startsWith("MySql") || entity.startsWith("SingleStore");
       out.tsType = "string";
       out.dbType = codec === "bit" ? "BIT" : "BINARY";
-      out.shape = {
+      out.shape = bytes ? { kind: "byteString", length: declaredLength(column) } : {
         kind: "bitstring",
         length: declaredLength(column),
-        // A Postgres `bit(3)` holds exactly three digits; a MySQL `binary(4)`/`varbinary(16)`
-        // holds at most that many, which is why `''` is valid there and not here.
+        // A Postgres `bit(3)` holds exactly three digits; a Cockroach `varbit(16)` holds at
+        // most that many, which is why `''` is valid there and not here.
         exact: codec === "bit"
       };
       break;
+    }
     case "point":
     case "geometry":
       out.tsType = "[number, number]";
@@ -556,12 +565,33 @@ var _SchemaAnalyzer = class _SchemaAnalyzer {
         return { tsType: "bigint", dbType: "BIGINT" };
       case "SQLiteNumeric":
         return { tsType: "string", dbType: "NUMERIC" };
+      // The other two modes of the same column, which matched no arm here and no dialect regex
+      // below either, so both came back UNKNOWN and every generator emitted a schema that
+      // accepted anything at all. Read back through better-sqlite3 3.53.4 on a `numeric` column,
+      // `db.select()` hands back a number in number mode and a bigint in bigint mode.
+      case "SQLiteNumericNumber":
+        return { tsType: "number", dbType: "NUMERIC" };
+      case "SQLiteNumericBigInt":
+        return { tsType: "bigint", dbType: "NUMERIC" };
       case "SQLiteBoolean":
         return { tsType: "boolean", dbType: "INTEGER" };
       // 0.4x gives an enum its own class, which had no arm here at all, so an enum column came
       // back `unknown` and every generator emitted a schema that accepted anything. The values
       // were on the column the whole time, in `enumValues`, waiting for a type to attach to.
+      //
+      // The MySQL and SingleStore classes were added later than the Postgres one, and their
+      // absence showed up somewhere unexpected: the emitted validator was already right, because
+      // every generator reads `enumValues` before it reads `tsType`, so the only thing wrong was
+      // the description. That description reached the user anyway, through the untyped-column
+      // warning, which said an enum column "will accept any value" while the emitted schema
+      // accepted exactly three. A warning that is wrong about the one thing it names is worse
+      // than no warning, because it teaches the reader to skip the true ones.
+      //
+      // v1 already answered `string` here, so this is also the two majors agreeing again rather
+      // than a new opinion; the cross-major diff carried the disagreement as a filed defect.
       case "PgEnumColumn":
+      case "MySqlEnumColumn":
+      case "SingleStoreEnumColumn":
         return { tsType: "string", dbType: "TEXT" };
       case "PgInteger":
       case "PgSmallInt":
@@ -600,6 +630,15 @@ var _SchemaAnalyzer = class _SchemaAnalyzer {
         return { tsType: "Date", dbType: "TIMESTAMP" };
       case "PgNumeric":
         return { tsType: "string", dbType: "NUMERIC" };
+      // The other two modes, each its own class. `PgNumericNumber` reached the coarse
+      // `/Numeric|Float|Double|Real/i` arm and got the right answer there; `PgNumericBigInt` got
+      // its `bigint` from the `/BigInt/i` arm meant for `bigint` columns, and the SQL label that
+      // comes with it, so a `numeric(20,0)` was reported as a BIGINT column. Read back through
+      // PGlite, `db.select()` hands back a number in number mode and a bigint in bigint mode.
+      case "PgNumericNumber":
+        return { tsType: "number", dbType: "NUMERIC" };
+      case "PgNumericBigInt":
+        return { tsType: "bigint", dbType: "NUMERIC" };
       case "PgDoublePrecision":
         return { tsType: "number", dbType: "DOUBLE" };
       // `real()` builds a `PgReal`, which matched no arm and fell through to the coarse
@@ -622,6 +661,16 @@ var _SchemaAnalyzer = class _SchemaAnalyzer {
       case "PgJson":
       case "PgJsonb":
         return { tsType: "any", dbType: ctor === "PgJsonb" ? "JSONB" : "JSON" };
+      // The four builders in `BYTE_STRING_CLASSES`, which the coarse `/Blob|Binary|VarBinary/i`
+      // arms below would otherwise call a `Uint8Array` on the strength of the word "Binary" in
+      // the class name. Asked of MySQL 8.4 through drizzle 0.45.2 instead: the driver hands up a
+      // Buffer, `mapFromDriverValue` decodes it, and the caller receives a string. Every one of
+      // the four declares `dataType: 'string'` and every one of the four defines that method.
+      case "MySqlBinary":
+      case "MySqlVarBinary":
+      case "SingleStoreBinary":
+      case "SingleStoreVarBinary":
+        return { tsType: "string", dbType: "BINARY" };
       default:
         if (column?.config?.mode === "timestamp" || column?.mode === "timestamp") {
           return { tsType: "Date", dbType: "INTEGER" };
@@ -649,7 +698,12 @@ var _SchemaAnalyzer = class _SchemaAnalyzer {
           if (/BigInt64/i.test(ctor)) return { tsType: "bigint", dbType: "BIGINT" };
           if (/BigInt53/i.test(ctor)) return { tsType: "number", dbType: "BIGINT" };
           if (/\bBigInt\b/i.test(ctor)) return { tsType: "bigint", dbType: "BIGINT" };
-          if (/Decimal|Numeric|Float|Double|Real/i.test(ctor))
+          if (/Decimal/i.test(ctor)) {
+            if (/DecimalNumber$/.test(ctor)) return { tsType: "number", dbType: "NUMERIC" };
+            if (/DecimalBigInt$/.test(ctor)) return { tsType: "bigint", dbType: "NUMERIC" };
+            return { tsType: "string", dbType: "NUMERIC" };
+          }
+          if (/Numeric|Float|Double|Real/i.test(ctor))
             return { tsType: "number", dbType: "NUMERIC" };
           if (/Int|Serial|TinyInt|SmallInt|MediumInt/i.test(ctor))
             return { tsType: "number", dbType: "INTEGER" };
@@ -668,7 +722,12 @@ var _SchemaAnalyzer = class _SchemaAnalyzer {
           if (/Vector/i.test(ctor)) return { tsType: "any", dbType: "VECTOR" };
           if (/BigInt64/i.test(ctor)) return { tsType: "bigint", dbType: "BIGINT" };
           if (/BigInt53/i.test(ctor)) return { tsType: "number", dbType: "BIGINT" };
-          if (/Decimal|Numeric|Float|Double|Real/i.test(ctor))
+          if (/Decimal/i.test(ctor)) {
+            if (/DecimalNumber$/.test(ctor)) return { tsType: "number", dbType: "NUMERIC" };
+            if (/DecimalBigInt$/.test(ctor)) return { tsType: "bigint", dbType: "NUMERIC" };
+            return { tsType: "string", dbType: "NUMERIC" };
+          }
+          if (/Numeric|Float|Double|Real/i.test(ctor))
             return { tsType: "number", dbType: "NUMERIC" };
           if (/Int|Serial|TinyInt|SmallInt|MediumInt/i.test(ctor))
             return { tsType: "number", dbType: "INTEGER" };
@@ -740,7 +799,9 @@ var _SchemaAnalyzer = class _SchemaAnalyzer {
       const sqlKind = String(outerCol?.constructor?.[/* @__PURE__ */ Symbol.for("drizzle:entityKind")] ?? "");
       const sqlType = sqlKind.startsWith("MySql") && typeof col?.getSQLType === "function" ? String(col.getSQLType()).toLowerCase() : void 0;
       const byteCap = sqlType ? MYSQL_TEXT_CAPS[sqlType] : void 0;
-      const fallbackShape = dbType === "JSON" || dbType === "JSONB" || col?.config?.mode === "json" ? { kind: "json" } : TUPLE_CLASS_SHAPES[String(col?.constructor?.name ?? "")];
+      const ctorName = String(col?.constructor?.name ?? "");
+      const fallbackShape = dbType === "JSON" || dbType === "JSONB" || col?.config?.mode === "json" ? { kind: "json" } : BYTE_STRING_CLASSES.has(ctorName) ? { kind: "byteString", length: declaredLength(col) } : TUPLE_CLASS_SHAPES[ctorName];
+      if (fallbackShape?.kind === "byteString") delete constraints.maxLength;
       const shape = (v1?.shape ?? fallbackShape)?.kind;
       const finalTs = v1?.tsType ?? tsType;
       const wide = (finalTs === "unknown" || finalTs === "any") && (!shape || shape === "custom");

package/dist/index.d.cts

@@ -144,16 +144,44 @@ type ColumnShape =
     sqlType?: string;
 }
 /**
- * A string of `0`/`1`: Postgres `bit(n)`, MySQL `binary(n)`/`varbinary(n)`.
+ * A string of `0`/`1`: Postgres `bit(n)`, Cockroach `bit(n)`/`varbit(n)`.
  *
- * `exact` separates the two. A Postgres `bit(3)` is always three digits, while a MySQL
- * `varbinary(16)` is at most sixteen, so treating both as exact rejected the empty string on
- * every MySQL binary column.
+ * `exact` separates the two. A Postgres `bit(3)` is always three digits, while a Cockroach
+ * `varbit(16)` is at most sixteen, so treating both as exact rejects the empty string on every
+ * varying column.
+ *
+ * MySQL `binary(n)`/`varbinary(n)` used to be listed here and is not a bit string at all; see
+ * `byteString`.
  */
  | {
     kind: 'bitstring';
     length?: number;
     exact?: boolean;
+}
+/**
+ * MySQL/SingleStore `binary(n)`/`varbinary(n)`: arbitrary bytes, handed to the caller as a
+ * string.
+ *
+ * Asked of MySQL 8.4 through drizzle on both majors, on the same row of the same table: the
+ * driver hands up a Buffer, drizzle decodes it, and what the caller receives is a string on
+ * 0.45.2 and on 1.0.0-rc.4 alike. `instanceof Uint8Array` is false for all four column builders
+ * on both majors.
+ *
+ * `length` is the declared width and means two different things depending on direction, which
+ * is why it is carried raw here rather than as a `maxLength` or a `maxBytes`:
+ *
+ *   out   the decode is lossy, so n bytes become at most n code points. Measured: `<ff ff ff>`
+ *         in a varbinary(3) comes back as 3 code points that re-encode to 9 UTF-8 bytes, so a
+ *         byte cap applied to a select schema rejects a row the column itself returned.
+ *   in    the server counts the encoded bytes. Measured on varbinary(8): 8 ascii accepted, 9
+ *         refused, 2 emoji (8 bytes) accepted, 3 emoji (12 bytes) refused, so a code-point cap
+ *         applied to an insert schema accepts a write the server refuses.
+ *
+ * The generators pick which by mode.
+ */
+ | {
+    kind: 'byteString';
+    length?: number;
 };
 interface Key {
     name?: string;

package/dist/index.d.ts

@@ -144,16 +144,44 @@ type ColumnShape =
     sqlType?: string;
 }
 /**
- * A string of `0`/`1`: Postgres `bit(n)`, MySQL `binary(n)`/`varbinary(n)`.
+ * A string of `0`/`1`: Postgres `bit(n)`, Cockroach `bit(n)`/`varbit(n)`.
  *
- * `exact` separates the two. A Postgres `bit(3)` is always three digits, while a MySQL
- * `varbinary(16)` is at most sixteen, so treating both as exact rejected the empty string on
- * every MySQL binary column.
+ * `exact` separates the two. A Postgres `bit(3)` is always three digits, while a Cockroach
+ * `varbit(16)` is at most sixteen, so treating both as exact rejects the empty string on every
+ * varying column.
+ *
+ * MySQL `binary(n)`/`varbinary(n)` used to be listed here and is not a bit string at all; see
+ * `byteString`.
  */
  | {
     kind: 'bitstring';
     length?: number;
     exact?: boolean;
+}
+/**
+ * MySQL/SingleStore `binary(n)`/`varbinary(n)`: arbitrary bytes, handed to the caller as a
+ * string.
+ *
+ * Asked of MySQL 8.4 through drizzle on both majors, on the same row of the same table: the
+ * driver hands up a Buffer, drizzle decodes it, and what the caller receives is a string on
+ * 0.45.2 and on 1.0.0-rc.4 alike. `instanceof Uint8Array` is false for all four column builders
+ * on both majors.
+ *
+ * `length` is the declared width and means two different things depending on direction, which
+ * is why it is carried raw here rather than as a `maxLength` or a `maxBytes`:
+ *
+ *   out   the decode is lossy, so n bytes become at most n code points. Measured: `<ff ff ff>`
+ *         in a varbinary(3) comes back as 3 code points that re-encode to 9 UTF-8 bytes, so a
+ *         byte cap applied to a select schema rejects a row the column itself returned.
+ *   in    the server counts the encoded bytes. Measured on varbinary(8): 8 ascii accepted, 9
+ *         refused, 2 emoji (8 bytes) accepted, 3 emoji (12 bytes) refused, so a code-point cap
+ *         applied to an insert schema accepts a write the server refuses.
+ *
+ * The generators pick which by mode.
+ */
+ | {
+    kind: 'byteString';
+    length?: number;
 };
 interface Key {
     name?: string;

package/dist/index.js

@@ -29,6 +29,12 @@ var TUPLE_CLASS_SHAPES = {
   PgLineTuple: { kind: "tuple", length: 3 }
 };
 var V1_ONLY_ENTITY_KINDS = /^(?:MsSql|Cockroach)/;
+var BYTE_STRING_CLASSES = /* @__PURE__ */ new Set([
+  "MySqlBinary",
+  "MySqlVarBinary",
+  "SingleStoreBinary",
+  "SingleStoreVarBinary"
+]);
 function describeV1Column(column) {
   const codec = column?.codec;
   const dataType = column?.dataType;
@@ -129,17 +135,20 @@ function describeV1Column(column) {
       out.tsType = "string";
       out.dbType = semantic.toUpperCase();
       break;
-    case "binary":
+    case "binary": {
+      const entity = String(column?.constructor?.[/* @__PURE__ */ Symbol.for("drizzle:entityKind")] ?? "");
+      const bytes = entity.startsWith("MySql") || entity.startsWith("SingleStore");
       out.tsType = "string";
       out.dbType = codec === "bit" ? "BIT" : "BINARY";
-      out.shape = {
+      out.shape = bytes ? { kind: "byteString", length: declaredLength(column) } : {
         kind: "bitstring",
         length: declaredLength(column),
-        // A Postgres `bit(3)` holds exactly three digits; a MySQL `binary(4)`/`varbinary(16)`
-        // holds at most that many, which is why `''` is valid there and not here.
+        // A Postgres `bit(3)` holds exactly three digits; a Cockroach `varbit(16)` holds at
+        // most that many, which is why `''` is valid there and not here.
         exact: codec === "bit"
       };
       break;
+    }
     case "point":
     case "geometry":
       out.tsType = "[number, number]";
@@ -515,12 +524,33 @@ var _SchemaAnalyzer = class _SchemaAnalyzer {
         return { tsType: "bigint", dbType: "BIGINT" };
       case "SQLiteNumeric":
         return { tsType: "string", dbType: "NUMERIC" };
+      // The other two modes of the same column, which matched no arm here and no dialect regex
+      // below either, so both came back UNKNOWN and every generator emitted a schema that
+      // accepted anything at all. Read back through better-sqlite3 3.53.4 on a `numeric` column,
+      // `db.select()` hands back a number in number mode and a bigint in bigint mode.
+      case "SQLiteNumericNumber":
+        return { tsType: "number", dbType: "NUMERIC" };
+      case "SQLiteNumericBigInt":
+        return { tsType: "bigint", dbType: "NUMERIC" };
       case "SQLiteBoolean":
         return { tsType: "boolean", dbType: "INTEGER" };
       // 0.4x gives an enum its own class, which had no arm here at all, so an enum column came
       // back `unknown` and every generator emitted a schema that accepted anything. The values
       // were on the column the whole time, in `enumValues`, waiting for a type to attach to.
+      //
+      // The MySQL and SingleStore classes were added later than the Postgres one, and their
+      // absence showed up somewhere unexpected: the emitted validator was already right, because
+      // every generator reads `enumValues` before it reads `tsType`, so the only thing wrong was
+      // the description. That description reached the user anyway, through the untyped-column
+      // warning, which said an enum column "will accept any value" while the emitted schema
+      // accepted exactly three. A warning that is wrong about the one thing it names is worse
+      // than no warning, because it teaches the reader to skip the true ones.
+      //
+      // v1 already answered `string` here, so this is also the two majors agreeing again rather
+      // than a new opinion; the cross-major diff carried the disagreement as a filed defect.
       case "PgEnumColumn":
+      case "MySqlEnumColumn":
+      case "SingleStoreEnumColumn":
         return { tsType: "string", dbType: "TEXT" };
       case "PgInteger":
       case "PgSmallInt":
@@ -559,6 +589,15 @@ var _SchemaAnalyzer = class _SchemaAnalyzer {
         return { tsType: "Date", dbType: "TIMESTAMP" };
       case "PgNumeric":
         return { tsType: "string", dbType: "NUMERIC" };
+      // The other two modes, each its own class. `PgNumericNumber` reached the coarse
+      // `/Numeric|Float|Double|Real/i` arm and got the right answer there; `PgNumericBigInt` got
+      // its `bigint` from the `/BigInt/i` arm meant for `bigint` columns, and the SQL label that
+      // comes with it, so a `numeric(20,0)` was reported as a BIGINT column. Read back through
+      // PGlite, `db.select()` hands back a number in number mode and a bigint in bigint mode.
+      case "PgNumericNumber":
+        return { tsType: "number", dbType: "NUMERIC" };
+      case "PgNumericBigInt":
+        return { tsType: "bigint", dbType: "NUMERIC" };
       case "PgDoublePrecision":
         return { tsType: "number", dbType: "DOUBLE" };
       // `real()` builds a `PgReal`, which matched no arm and fell through to the coarse
@@ -581,6 +620,16 @@ var _SchemaAnalyzer = class _SchemaAnalyzer {
       case "PgJson":
       case "PgJsonb":
         return { tsType: "any", dbType: ctor === "PgJsonb" ? "JSONB" : "JSON" };
+      // The four builders in `BYTE_STRING_CLASSES`, which the coarse `/Blob|Binary|VarBinary/i`
+      // arms below would otherwise call a `Uint8Array` on the strength of the word "Binary" in
+      // the class name. Asked of MySQL 8.4 through drizzle 0.45.2 instead: the driver hands up a
+      // Buffer, `mapFromDriverValue` decodes it, and the caller receives a string. Every one of
+      // the four declares `dataType: 'string'` and every one of the four defines that method.
+      case "MySqlBinary":
+      case "MySqlVarBinary":
+      case "SingleStoreBinary":
+      case "SingleStoreVarBinary":
+        return { tsType: "string", dbType: "BINARY" };
       default:
         if (column?.config?.mode === "timestamp" || column?.mode === "timestamp") {
           return { tsType: "Date", dbType: "INTEGER" };
@@ -608,7 +657,12 @@ var _SchemaAnalyzer = class _SchemaAnalyzer {
           if (/BigInt64/i.test(ctor)) return { tsType: "bigint", dbType: "BIGINT" };
           if (/BigInt53/i.test(ctor)) return { tsType: "number", dbType: "BIGINT" };
           if (/\bBigInt\b/i.test(ctor)) return { tsType: "bigint", dbType: "BIGINT" };
-          if (/Decimal|Numeric|Float|Double|Real/i.test(ctor))
+          if (/Decimal/i.test(ctor)) {
+            if (/DecimalNumber$/.test(ctor)) return { tsType: "number", dbType: "NUMERIC" };
+            if (/DecimalBigInt$/.test(ctor)) return { tsType: "bigint", dbType: "NUMERIC" };
+            return { tsType: "string", dbType: "NUMERIC" };
+          }
+          if (/Numeric|Float|Double|Real/i.test(ctor))
             return { tsType: "number", dbType: "NUMERIC" };
           if (/Int|Serial|TinyInt|SmallInt|MediumInt/i.test(ctor))
             return { tsType: "number", dbType: "INTEGER" };
@@ -627,7 +681,12 @@ var _SchemaAnalyzer = class _SchemaAnalyzer {
           if (/Vector/i.test(ctor)) return { tsType: "any", dbType: "VECTOR" };
           if (/BigInt64/i.test(ctor)) return { tsType: "bigint", dbType: "BIGINT" };
           if (/BigInt53/i.test(ctor)) return { tsType: "number", dbType: "BIGINT" };
-          if (/Decimal|Numeric|Float|Double|Real/i.test(ctor))
+          if (/Decimal/i.test(ctor)) {
+            if (/DecimalNumber$/.test(ctor)) return { tsType: "number", dbType: "NUMERIC" };
+            if (/DecimalBigInt$/.test(ctor)) return { tsType: "bigint", dbType: "NUMERIC" };
+            return { tsType: "string", dbType: "NUMERIC" };
+          }
+          if (/Numeric|Float|Double|Real/i.test(ctor))
             return { tsType: "number", dbType: "NUMERIC" };
           if (/Int|Serial|TinyInt|SmallInt|MediumInt/i.test(ctor))
             return { tsType: "number", dbType: "INTEGER" };
@@ -699,7 +758,9 @@ var _SchemaAnalyzer = class _SchemaAnalyzer {
       const sqlKind = String(outerCol?.constructor?.[/* @__PURE__ */ Symbol.for("drizzle:entityKind")] ?? "");
       const sqlType = sqlKind.startsWith("MySql") && typeof col?.getSQLType === "function" ? String(col.getSQLType()).toLowerCase() : void 0;
       const byteCap = sqlType ? MYSQL_TEXT_CAPS[sqlType] : void 0;
-      const fallbackShape = dbType === "JSON" || dbType === "JSONB" || col?.config?.mode === "json" ? { kind: "json" } : TUPLE_CLASS_SHAPES[String(col?.constructor?.name ?? "")];
+      const ctorName = String(col?.constructor?.name ?? "");
+      const fallbackShape = dbType === "JSON" || dbType === "JSONB" || col?.config?.mode === "json" ? { kind: "json" } : BYTE_STRING_CLASSES.has(ctorName) ? { kind: "byteString", length: declaredLength(col) } : TUPLE_CLASS_SHAPES[ctorName];
+      if (fallbackShape?.kind === "byteString") delete constraints.maxLength;
       const shape = (v1?.shape ?? fallbackShape)?.kind;
       const finalTs = v1?.tsType ?? tsType;
       const wide = (finalTs === "unknown" || finalTs === "any") && (!shape || shape === "custom");

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@drzl/analyzer",
-  "version": "1.16.0",
+  "version": "1.17.1",
   "private": false,
   "license": "Apache-2.0",
   "type": "module",