Allow arbitrary enum values

Problem

Enums currently prevent certain values from being used, requiring use of @map() to correctly reflect what actually gets stored in the database.

This causes a couple of issues:

1. There is no Prisma-provided mechanism for accessing the underlying value, as would be needed if/when the mapped value needs to be accessed / returned / shown to users.
2. It seems unnecessary, looking at the code that is generated for the JavaScript/TypeScript client.

eg: The following are currently not allowed:

enum Place {
  1st
  2nd
  3rd
}

enum AddressUnitType {
  "Apt."
  Suite
  Unit
}

Note: enum identifiers having embedded spaces are also not allowed.

Instead, they require the use of @map("{value}") like this:

enum Place {
  first @map("1st")
  second @map("2nd")
  third @map("3rd")
}

enum AddressUnitType {
  Apt @map("Apt.")
  Suite
  Unit
}

Additionally, since Prisma does not currently provide a supported mechanism for translating between the mapped enum values and the enum identifiers, this is another layer of translation that has to be provided.

Suggested solution

Allow Prisma enums to be defined using enclosing double-quotes if needed

eg:

enum Place {
  "1st"
  "2nd"
  "3rd"
}

enum AddressUnitType {
  "Apt."
  Suite
  Unit
}

This will avoid the need to use any other translation of the identifier to the value, too.

I do imagine that the Prisma architects are being restrictive here, and wanting to take the ‘lowest common denominator’, so that, should they want to add generators for other languages, particularly those that natively provide their own enum types, and which there, have restrictions similar to what Prisma is currently imposing.

Perhaps in that case, when the project is known to only ever need JavaScript/TypeScript client generation, there should be a configuration option that can be set to indicate relaxation of the enum value restrictions, given those restrictions will never be encountered.

Alternatives

Additional context

[SamuelMS]

@janpio Considering enum types in TypeScript are currently generated as key-value pairs, could we update the generated value to be the @map representation instead?

i.e. for the schema

enum Role {
  EMPLOYEE       @map(name: "Employee")
  COMPANY_ADMIN  @map(name: "Company Admin")
}

This is what gets generated:

export const Role: {
  EMPLOYEE: 'EMPLOYEE',
  COMPANY_ADMIN: 'COMPANY_ADMIN'
};

So anything that consumes the type needs to translate COMPANY_ADMIN to Company Admin. However, no translation would be necessary if the generated type were switched to this instead:

export const Role: {
  EMPLOYEE: 'Employee',
  COMPANY_ADMIN: 'Company Admin'
};

[AndrewSouthpaw]

Hey folks, I just wanted to remind people that a feature not being prioritized isn’t an excuse to be rude to others. Social shaming in comments like the one above aren’t particularly effective at getting work onto a backlog. I’m sure the Prisma team understands this feature is widely desired by the community, and will be weighing that against other work they need to do to support the product and the company. If you’re paying for premium support with Prisma, use that as an avenue to provide signals. If you’re using this awesome library for free, provide the signal by +1’ing the OP and providing feedback to team members on use cases not already covered.

We’re all in this together, let’s try to be respectful. ❤️