Can we get rid of enums?

[mattiaz9]

Enums are kind of a mess. Changing an existing enum causes several problems and I'm not even sure what advantages could possible have for a cms.
Every time a new select field is added, a new enum is created every time, even when the same values are reused across multiple entities.
I just tried to remove a value from a select options and now it's all broken. I keep getting the error enum label "zoom" already exists, even after deleting and recreating the field.

It just makes no sense to me to have such a constrained type. It creates more problems than it solves.

[r1tsuu]

@mattiaz9 Hey, are you on 2.0? I think issues with changing select / group fields values are related to the old drizzle version that's not currently updated there (it is on 3.0 beta).
However, we have a huge PR #8468 for 2.0 that should fix this!

[mattiaz9]

no, I'm on version 3.0.0-beta.109

[revnelson]

Amen! I'm having this issue in v3 beta also. In addition, I have a select field nested in a block that's nested in a Pages collection fields. I got an error saying the enum name was too long.

Error: Exceeded max identifier length for table or enum name of 63 characters. Invalid name: enum_pages_blocks_test_block_options_time_filter_show_from_timezone

[DanRibbens]

You can override the generated enum names using the enumName property in the select field.

[revnelson]

Any attempt I made at generating my own enumName ended in the duplicate value error above.

[DanRibbens]

Make your enumName a function and use the incoming args to make the name unique.

[DanRibbens]

There is an ongoing issue that drizzle knows about. We've been looking at ways to solve the underlying problem. I do think that enums offer some benefit over making everything a text field.

Until it is fixed what you can do to workaround the issue is add push: false to your database adapter properties in the payload config. Then use the migrate commands payload migrate:create, modify the up and down functions to fix the issue described above by removing the extra enum labels. Then you should be able to migrate without error and push your changes.

If we decide to remove the use enums, it would be a flag to opt-out of this behavior which I totally understand might be helpful to some.

[mattiaz9]

why not a simple option enum: false. Let it be handled as a string if false, so at least we can choose.

[DanRibbens]

I'm not opposed to that as an option. We just have a lot of complexity already in the adapter and this hasn't been prioritized, but this makes sense to me.

PRs are welcome ;)

[VVVi]

I also got this error in v3 beta.111 It looks, like it is related to ordering items in enum. In my case, I have changed options' ordering for select type field, and seems it wants to add a new enum label, that already exists. Related issue from Drizzle drizzle-team/drizzle-orm#2389

[tomparkp]

This recently came up in a Discord discussion and I think it's probably going to come up a lot more often now that v3 is stable. Definitely understand that enums offer benefits but now that Payload released a Lexical -> JSX adapter this is the only aspect of Payload that feels a bit rough IMO.

The default push DB behavior in development (which is great) results in this coming up quite frequently when developing with the only option seemingly being either abandoning push for manual migrations or dropping the relevant field and replacing it (which is okay when prototyping but not if you have data you don't want to lose).

Even when doing things like dropping the field entirely it leaves enum values in the DB which can cause conflicts and errors down the road if those values are reused.

The ideal solution would obviously be Drizzle finding a way upstream to make the "rename field" option handle it correctly vs creating a runtime error but seems like it could be a while. In the meantime it might be worth mentioning this in the docs around things like select fields.

A flag as suggested would also be great. I'd love to contribute to Payload but currently the CTO/sole developer at my company so don't have much spare time, might try to delve into a PR if I can find time over the holidays.

[DanRibbens]

Are you still getting the same error as was originally reported, "Label already exists" when removing options from a select field?

I'm not opposed to making it more flexible, but first it's important to cover the intended behavior.

[r1tsuu]

For anyone who has issues with them, beforeSchemaInit hook to opt of enums:

postgresAdapter({
  pool: {
    connectionString: process.env.DATABASE_URI || '',
  },
  beforeSchemaInit: [
    ({ schema, adapter }) => {
      for (const tableName in adapter.rawTables) {
        const table = adapter.rawTables[tableName]

        for (const fieldName in table.columns) {
          const column = table.columns[fieldName]

          if (column.type === 'enum') {
            ;(column as any).type = 'varchar'
          }
        }
      }
      return schema
    },
  ],
})