strict mode

[araera111]

for example

tinyint -128to127 or 0to255 (from table definition)
smallint -32768to32767 or 0to65535

I want to create a strict mode based on the MySQL specification.

export const strictTypeUnionSchema = z.union([
  z.literal("TINYINT"),
  z.literal("SMALLINT"),
// etc
]);

export const mysqlToZodOptionSchema = z.object({
  isAddType: z.boolean().optional().default(true),
  isCamel: z.boolean().optional().default(true),
  isTypeUpperCamel: z.boolean().optional().default(true),
  outFilePath: z.string().optional().default("./mysqlToZod"),
  fileName: z.string().optional().default("schema.ts"),
  dbConnection: z.any().optional(),
  tableNames: z.string().array().optional().default([]),
  nullType: z
    .union([z.literal("nullable"), z.literal("nullish")])
    .optional()
    .default("nullable"),
  strictTypeList: strictTypeUnionSchema.array().optional().default([]), // add
// or notStrictTypeList: ???
// or isStrict bool -> true all strict _ false not strict
});

I'm thinking about how to specify options; would the format of specifying what you want to be strict be good? Or should I specify what I don't want to be strict? Do most people want to use a strict zod schema or not? Which would it be?

[TonyGravagno]

Please see my fork of the MySQL-Zod project (the "other" utility that's like MySQL-to-Zod).

In the README for this branch where the JSON options are documented, I have a "datetime" node that provides many options for how this type is processed. My point is that validation may not be limited purely to "strict" or "not strict", but within each type there may be other choices.

Yes, there can be a high-level default, with later options defining overrides. I've been thinking about a structure like this that can be implemented in the .js config file:

typeSpecs: pref1,
types: {
 default: { 
    datetime: { ... }
    smallint: { ... }
  },
 pref1: {
   datetime: { ... }
   smallint: { ... }
  },
}

By simply copy/pasting a preference and setting typeSpecs, a developer can generate code for a different application, and just reset it again to regenerate code for any database.

( Note, please ignore the branches and their code. It requires explanation outside of context. That code has not yet been PR'd upstream and may never go production. )