@drzl/analyzer 1.17.6 → 1.17.7

package/dist/index.cjs

@@ -106,6 +106,7 @@ function describeV1Column(column) {
   const out = {};
   switch (semantic) {
     case "int8":
+    case "uint8":
     case "int16":
     case "int24":
     case "int32":
@@ -122,6 +123,7 @@ function describeV1Column(column) {
       }
       const range = {
         int8: ["-128", "127"],
+        uint8: ["0", "255"],
         int16: ["-32768", "32767"],
         int24: ["-8388608", "8388607"],
         int32: ["-2147483648", "2147483647"],
@@ -134,7 +136,7 @@ function describeV1Column(column) {
       [out.min, out.max] = range;
       out.integer = true;
       out.tsType = js === "bigint" ? "bigint" : "number";
-      out.dbType = semantic === "int8" ? "TINYINT" : semantic === "int16" ? "SMALLINT" : semantic === "int24" ? "MEDIUMINT" : semantic === "int32" ? "INTEGER" : "BIGINT";
+      out.dbType = semantic === "int8" || semantic === "uint8" ? "TINYINT" : semantic === "int16" ? "SMALLINT" : semantic === "int24" ? "MEDIUMINT" : semantic === "int32" ? "INTEGER" : "BIGINT";
       break;
     }
     case "year":
@@ -183,6 +185,16 @@ function describeV1Column(column) {
       out.dbType = codec?.startsWith("timestamp") ? "TIMESTAMP" : "DATE";
       break;
     case "timestamp":
+    // `datetime` is the same fact under MySQL's name for it, and it had no arm, so every column
+    // stating it fell to the bare-string arm and was labelled TEXT. The columns that reach this
+    // are the string modes of `datetime` on mssql, mysql and singlestore, plus mssql's
+    // `datetime2` and `datetimeoffset`, swept over every builder the six v1 cores export; the
+    // `{ mode: 'date' }` half of the same builders states `object date` and takes the arm above.
+    // A label only, since `dbType` is read outside this file in exactly one place,
+    // `isIntegerColumn`, which the generators consult for a `tsType` of `number`. It matters
+    // because the class-name path already answers TIMESTAMP for the same 0.4x column, and the
+    // two majors disagreeing about a column is what the cross-major diff exists to catch.
+    case "datetime":
       out.tsType = js === "string" ? "string" : "Date";
       out.dbType = "TIMESTAMP";
       break;
@@ -204,13 +216,25 @@ function describeV1Column(column) {
       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.dbType = bytes ? "BINARY" : "BIT";
       out.shape = bytes ? { kind: "byteString", length: declaredLength(column) } : {
         kind: "bitstring",
         length: declaredLength(column),
         // 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"
+        //
+        // `codec === 'bit'` alone was Postgres's answer applied to everything, and Cockroach
+        // states no codec, so both of its builders came back `exact: false` and a `bit(3)`
+        // was indistinguishable from a `varbit(3)`. Measured on CockroachDB v24.3.5: a
+        // `bit(3)` refuses '', '1', '10' and '1011' with "bit string length n does not match
+        // type BIT(3)" and takes '101'; a `varbit(8)` takes '', '1' and '10101010' and
+        // refuses nine digits with "too large for type VARBIT(8)". `drizzle-orm/zod` at
+        // 1.0.0-rc.4 answers the same for both columns.
+        //
+        // The class rather than a prefix, because `CockroachVarbit` starts with neither
+        // `CockroachBit` nor anything else this could key on without catching the varying
+        // half too.
+        exact: codec === "bit" || entity === "CockroachBit"
       };
       break;
     }

package/dist/index.js

@@ -65,6 +65,7 @@ function describeV1Column(column) {
   const out = {};
   switch (semantic) {
     case "int8":
+    case "uint8":
     case "int16":
     case "int24":
     case "int32":
@@ -81,6 +82,7 @@ function describeV1Column(column) {
       }
       const range = {
         int8: ["-128", "127"],
+        uint8: ["0", "255"],
         int16: ["-32768", "32767"],
         int24: ["-8388608", "8388607"],
         int32: ["-2147483648", "2147483647"],
@@ -93,7 +95,7 @@ function describeV1Column(column) {
       [out.min, out.max] = range;
       out.integer = true;
       out.tsType = js === "bigint" ? "bigint" : "number";
-      out.dbType = semantic === "int8" ? "TINYINT" : semantic === "int16" ? "SMALLINT" : semantic === "int24" ? "MEDIUMINT" : semantic === "int32" ? "INTEGER" : "BIGINT";
+      out.dbType = semantic === "int8" || semantic === "uint8" ? "TINYINT" : semantic === "int16" ? "SMALLINT" : semantic === "int24" ? "MEDIUMINT" : semantic === "int32" ? "INTEGER" : "BIGINT";
       break;
     }
     case "year":
@@ -142,6 +144,16 @@ function describeV1Column(column) {
       out.dbType = codec?.startsWith("timestamp") ? "TIMESTAMP" : "DATE";
       break;
     case "timestamp":
+    // `datetime` is the same fact under MySQL's name for it, and it had no arm, so every column
+    // stating it fell to the bare-string arm and was labelled TEXT. The columns that reach this
+    // are the string modes of `datetime` on mssql, mysql and singlestore, plus mssql's
+    // `datetime2` and `datetimeoffset`, swept over every builder the six v1 cores export; the
+    // `{ mode: 'date' }` half of the same builders states `object date` and takes the arm above.
+    // A label only, since `dbType` is read outside this file in exactly one place,
+    // `isIntegerColumn`, which the generators consult for a `tsType` of `number`. It matters
+    // because the class-name path already answers TIMESTAMP for the same 0.4x column, and the
+    // two majors disagreeing about a column is what the cross-major diff exists to catch.
+    case "datetime":
       out.tsType = js === "string" ? "string" : "Date";
       out.dbType = "TIMESTAMP";
       break;
@@ -163,13 +175,25 @@ function describeV1Column(column) {
       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.dbType = bytes ? "BINARY" : "BIT";
       out.shape = bytes ? { kind: "byteString", length: declaredLength(column) } : {
         kind: "bitstring",
         length: declaredLength(column),
         // 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"
+        //
+        // `codec === 'bit'` alone was Postgres's answer applied to everything, and Cockroach
+        // states no codec, so both of its builders came back `exact: false` and a `bit(3)`
+        // was indistinguishable from a `varbit(3)`. Measured on CockroachDB v24.3.5: a
+        // `bit(3)` refuses '', '1', '10' and '1011' with "bit string length n does not match
+        // type BIT(3)" and takes '101'; a `varbit(8)` takes '', '1' and '10101010' and
+        // refuses nine digits with "too large for type VARBIT(8)". `drizzle-orm/zod` at
+        // 1.0.0-rc.4 answers the same for both columns.
+        //
+        // The class rather than a prefix, because `CockroachVarbit` starts with neither
+        // `CockroachBit` nor anything else this could key on without catching the varying
+        // half too.
+        exact: codec === "bit" || entity === "CockroachBit"
       };
       break;
     }

package/package.json

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