drizzle enums

[cehenriques]

Hi.

I just started recently using drizzle coming from Prisma, and I'm trying to convert one of my projects to drizzle.
One thing I found less intuitive is how Drizzle manages enums.
For instance, in Prisma, I would create an enum on my schema like this:

enum Color {
  Red
  Green
  Blue
}

model Theme {
  id           Int         @id @default(autoincrement())
  color     Color       
}

And then I could use it normally like this in my project:

const myColor = Color.Red;

But in drizzle, we create an enum as a PgEnum:

export const colorEnum = pgEnum("color", ["Red", "Green", "Blue"]);

But then to access its values I can only do it like so:

const myColor = colorEnum.enumValues[0];

I need to rely on the editor's intellisense

to remind me that "[0]" is "Red", while on Prisma's approach, I can use a traditional TS enum and directly access its values.
Am I doing something wrong? Is there a better or alternative way to use the enums?
What approach do you guys use? Do you just create an actual enum to reference it throughout your project?

Thanks in advance.

[nathanchapman]

Hey @cehenriques! I agree this would be nice. Gave you an upvote 🚀

For now, you can use two approaches:

Approach 1: the drizzle-zod plugin with Zod's enum support

https://orm.drizzle.team/docs/zod
https://zod.dev/?id=zod-enums

This would give you something like:

import { z } from 'zod';
import { pgEnum, pgTable, serial } from 'drizzle-orm/pg-core';
import { createSelectSchema } from 'drizzle-zod';

const colorEnum = pgEnum('color', ['Red', 'Green', 'Blue']);

const themes = pgTable('themes', {
  id: serial('id').primaryKey(),
  color: colorEnum('color').notNull(), // or nullable, will change enum usage mentioned below
});

const selectThemeSchema = createSelectSchema(themes);

type Theme = z.infer<typeof selectThemeSchema>;

// If column is nullable
selectThemeSchema.shape.color._def.innerType.enum.Blue;
// If column is not nullable
selectThemeSchema.shape.color.enum.Blue;

Approach 2: Use Zod enums directly with enumValues (a "cleaner" approach IMO)

import { z } from 'zod';
import { pgEnum, pgTable, serial } from 'drizzle-orm/pg-core';
import { createSelectSchema } from 'drizzle-zod';

const colorEnum = pgEnum('color', ['Red', 'Green', 'Blue']);
const colorEnumSchema = z.enum(colorEnum.enumValues);

const themes = pgTable('themes', {
  id: serial('id').primaryKey(),
  color: colorEnum('color'),
});

const selectThemeSchema = createSelectSchema(themes);
type Theme = z.infer<typeof selectThemeSchema>;

colorEnumSchema.enum.Blue;

Hope this helps for now!

[NielsCodes]

It's silly that we need to use drizzle-zod for such a basic feature

[nathanchapman]

It's silly that we need to use drizzle-zod for such a basic feature

You don't.. See approach 2. It's only used to create a select schema, which isn't actually required. You do however, have to use Zod to achieve this

[RobSchilderr]

Hey @cehenriques! I agree this would be nice. Gave you an upvote 🚀

For now, you can use two approaches:

Approach 1: the drizzle-zod plugin with Zod's enum support

https://orm.drizzle.team/docs/zod https://zod.dev/?id=zod-enums

This would give you something like:

import { z } from 'zod';
import { pgEnum, pgTable, serial } from 'drizzle-orm/pg-core';
import { createSelectSchema } from 'drizzle-zod';

const colorEnum = pgEnum('color', ['Red', 'Green', 'Blue']);

const themes = pgTable('themes', {
  id: serial('id').primaryKey(),
  color: colorEnum('color').notNull(), // or nullable, will change enum usage mentioned below
});

const selectThemeSchema = createSelectSchema(themes);

type Theme = z.infer<typeof selectThemeSchema>;

// If column is nullable
selectThemeSchema.shape.color._def.innerType.enum.Blue;
// If column is not nullable
selectThemeSchema.shape.color.enum.Blue;

Approach 2: Use Zod enums directly with enumValues (a "cleaner" approach IMO)

import { z } from 'zod';
import { pgEnum, pgTable, serial } from 'drizzle-orm/pg-core';
import { createSelectSchema } from 'drizzle-zod';

const colorEnum = pgEnum('color', ['Red', 'Green', 'Blue']);
const colorEnumSchema = z.enum(colorEnum.enumValues);

const themes = pgTable('themes', {
  id: serial('id').primaryKey(),
  color: colorEnum('color'),
});

const selectThemeSchema = createSelectSchema(themes);
type Theme = z.infer<typeof selectThemeSchema>;

colorEnumSchema.enum.Blue;

Hope this helps for now!

What is the reason for not inferring the colorEnumSchema with Approach 2, like:

export type ColorEnum = z.infer<typeof colorEnumSchema>

[Angelelz]

I don't use Zod, so I wanted to share what I've done before in a project.
I define a readonly array which will be my source of truth with the values that the enum needs.
I thought I could share some code in this playground. It relies on some typescript trickery though.

[sisimomo]

Very nice! Here's an enhanced version that leverages utility functions. This way, if it's applied across multiple enums, the approach is significantly tidier.

[ubinatus]

Thanks for sharing! Ended up doing the following in case anyone finds it helpful:

function createEnumObject<T extends string>(
  array: readonly T[],
): { [K in T]: K } {
  return array.reduce(
    (acc, cur) => {
      acc[cur] = cur;
      return acc;
    },
    {} as { [K in T]: K },
  );
}

// Example
const GlobalRole = ["SUPERADMIN", "CUSTOMER"] as const;
const GlobalRoleEnum = createEnumObject(GlobalRole); // { SUPERADMIN: "SUPERADMIN", CUSTOMER: "CUSTOMER" }
type GlobalRole = keyof typeof GlobalRoleEnum; // "SUPERADMIN" | "CUSTOMER"

[henritouchard]

Hello !
For those looking for another option, i decided to revert the logic with an utility function.
I first define my js enum, and, giving it to the function, I create the pgEnum.
I think it provides easier way to add enum values.
Here is the code:

// Takes an enum and return an array with each values
export function enumToPgEnum(myEnum: any): [string, ...string[]] {
  return Object.values(myEnum).map((value: any) => `${value}`) as [string, ...string[]]
}

// Define an enum
export enum Role {
  APPLICANT = 'applicant',
  TRAINER = 'trainer',
  ADMIN = 'admin',
}

// Declare drizzle enum
export const roleEnum = pgEnum('role', enumToPgEnum(Role))

I didn't use it a lot so i'm not sure this technique is perfect but it seems working for my current needs.

[Weixuanf]

this one worked for me! thanks for putting it out here:)

[aprilmintacpineda]

This won't infer the correct typings, now role has type of [string, ...string[] instead of Role.

[ap0nia]

export enum Role {
  APPLICANT = 'applicant',
  TRAINER = 'trainer',
  ADMIN = 'admin',
}

export function enumToPgEnum<T extends Record<string, any>>(
  myEnum: T,
): [T[keyof T], ...T[keyof T][]] {
  return Object.values(myEnum).map((value: any) => `${value}`) as any
}

export const roleEnum = pgEnum('role', enumToPgEnum(Role))

[andrewbellucci]

If you're just looking for the typings so you can reuse them elsewhere, you can achieve this without any extra dependencies.

Use the following as an example:

const onboardingSteps = ["welcome", "setup", "complete"] as const;
type OnboardingStep = typeof onboardingSteps[number];
const onboardingStepEnum = pgEnum("onboarding_step", onboardingSteps);

[aprilmintacpineda]

A simple work around that I found:

enum eMyEnum {
  Value1 = 'Value1',
  Value2 = 'Value2'
}

export const  myTable = mysqlTable("my_table", {
  // ...other fields
  myField: mysqlEnum(
    "my_field",
     Object.values(eCategoryType) as [eCategoryType, ...eCategoryType[]]
  )
});

This will also keep the type so later when you query the table, myField will be of type eMyEnum.

const values = await db.query.myTable.findMany();

values.forEach(value => {
  value.myField // will be of type eMyEnum
});

The reason for this is because mysqlEnum is typed as [string, ...string[]] which is the same as string[] BUT it requires at least 1 element. So ['test'] would be a valid [string, ...string[]] and also a valid string[] BUT [] would NOT be a valid [string, ...string[]] but is a valid string[]

[Weixuanf]

ohhh actually this one worked best, as [eCategoryType, ...eCategoryType[]] this is much better than [string, ...string[]!

[incompletude]

Not trying to be harsh, but I think the Drizzle team is missing the point. What we expect from a TypeScript ORM is that it provides the types we are working with. Prisma and TypeORM offer this out of the box, while Drizzle expects us to infer types or even pre-create them ourselves to do some additional work for them to be used by Drizzle.

[NielsCodes]

I didn't mean to imply that either, sorry! I just meant that TypeORM just takes a different approach to solving this "problem", which has its own pitfalls. But a more apples-to-apples comparison to Prisma indeed shows how cumbersome this very simple use case is in Drizzle. And like you, I decided to stick with Prisma for now.

So we're actually completely in agreement 😅

[aprilmintacpineda]

In Drizzle and Prisma, you define your schema first which then generates Typescript types.

I don't think you're right. Drizzle DOES NOT generate typescript types. It uses types you pass to mysqlTable or similar functions.

Prisma, generates TS Types, Drizzle doesn't. A matter of fact, you have to generate these TS types when you update your prisma schema, you don't do that with drizzle when you update your model definitions do you?

In TypeORM you define classes in your code, which then lead to a database schema.

In drizzle, you define your table which can be thought of as models / repositories, the collection of which leads to your database schema.

Again, drizzle does not generate TS Types, we should get semantics correctly. That's like saying that Generics in typescript generates TS Types. Drizzle uses generics.

The problem is with this piece of code https://github.com/drizzle-team/drizzle-orm/blob/main/drizzle-orm/src/mysql-core/columns/enum.ts#L51, as you can see, it insists that the type should be [U, ...U[]] where U is defined as U extends string, so it ends up being [string, ...string[]].

[aprilmintacpineda]

We can change it to:

export declare function mysqlEnum<TName extends string, U extends string, T extends ReadonlyArray<U>>(name: TName, values: T): MySqlEnumColumnBuilderInitial<TName, Writable<T>>;

which will work:

const types = mysqlEnum(
  'type',
  Object.values(eCategoryType),
).notNull();

The problem is, it will accept empty arrays:

const types = mysqlEnum('type', []).notNull();

Which from my perspective actually works. I see no problem with this. However, unlike with the original definition, it will NOT throw an error, which I think is what the Drizzle team is actually going for.

Argument of type '[]' is not assignable to parameter of type 'readonly [string, ...string[]] | [string, ...string[]]'.
  Type '[]' is not assignable to type '[string, ...string[]]'.
    Source has 0 element(s) but target requires 1.ts(2345)

Anyways, I don't know if there's already an existing PR for this, if not, I can create one. TypeScript is a bit problematic when it comes to enums.

[aprilmintacpineda]

Well, I made it anyways #2429 this one also includes workaround to get ride of the as keyword.

[incompletude]

Well, I made it anyways #2429 this one also includes workaround to get ride of the as keyword.

All of this is very nice, but I still maintain that Drizzle is missing the point. Once I have defined my schema, all the related types should be available for use across the system. There is no point in inferselect, and to precreate enums to get this working.

[berkesandras]

If it's ok to use string unions instead of enums, here's my approach:

const colors = pgEnum("colors", ["Red", "Green", "Blue"]);
type Color = (typeof colors.enumValues)[number];