Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

LogLevel enum conflicts with built-in Prisma type #20031

Closed
MansurAliKoroglu opened this issue Jul 1, 2023 · 1 comment · Fixed by #20194
Closed

LogLevel enum conflicts with built-in Prisma type #20031

MansurAliKoroglu opened this issue Jul 1, 2023 · 1 comment · Fixed by #20194
Assignees
Labels
bug/2-confirmed Bug has been reproduced and confirmed. kind/bug A reported bug. team/client Issue for team Client. tech/typescript Issue for tech TypeScript. topic: enum "type"/block `enum` topic: type-clash
Milestone

Comments

@MansurAliKoroglu
Copy link

Bug description

I created an enum called LogLevel and used in my model. Model's create type is different than LogLevel enum type. So, this:

  await prismaClient.log.create({
    data: {
      level: LogLevel.INFO
    }
  });

fails typescript with Type '"INFO"' is not assignable to type 'LogLevel'. Did you mean '"info"'?ts(2820)


When I change enum name to Level types are correct.

How to reproduce

  1. Create minimal ts project with just index.ts
  2. Install prisma and @prisma/client and init + create + migrate enum and model
enum LogLevel {
  INFO
  WARN
}

model Log {
  id    Int      @id @default(autoincrement())
  level LogLevel
}
  1. Write code in index.ts
import { LogLevel, PrismaClient } from '@prisma/client'

(async () => {
  const prismaClient = new PrismaClient();

  await prismaClient.log.create({
    data: {
      level: LogLevel.INFO
    }
  });
})()
  1. Try to build ts and see error Type '"INFO"' is not assignable to type 'LogLevel'. Did you mean '"info"'?ts(2820)
  2. Optionally, remove migration, change enum's name to Level and migrate + generate again to see no error with Level.INFO now.

Expected behavior

Generated types should be correct regardless enum's name

Prisma information

generator client {
  provider = "prisma-client-js"
}

datasource db {
  provider = "postgresql"
  url      = env("DATABASE_URL")
}

enum Level {
  INFO
  WARN
}

model Log {
  id    Int      @id @default(autoincrement())
  level Level
}
import { Level, PrismaClient } from '@prisma/client'

(async () => {
  const prismaClient = new PrismaClient();

  await prismaClient.log.create({
    data: {
      level: Level.INFO
    }
  });
})()

Environment & setup

  • OS: Kubuntu 22.04, Kernel version: 5.15.0-76-generic (64-bit)
  • Database: PostgreSQL
  • Node.js version: 18.16.0

Prisma Version

prisma                  : 4.16.2
@prisma/client          : 4.16.2
Current platform        : debian-openssl-3.0.x
Query Engine (Node-API) : libquery-engine 4bc8b6e1b66cb932731fb1bdbbc550d1e010de81 (at node_modules/@prisma/engines/libquery_engine-debian-openssl-3.0.x.so.node)
Migration Engine        : migration-engine-cli 4bc8b6e1b66cb932731fb1bdbbc550d1e010de81 (at node_modules/@prisma/engines/migration-engine-debian-openssl-3.0.x)
Format Wasm             : @prisma/prisma-fmt-wasm 4.16.1-1.4bc8b6e1b66cb932731fb1bdbbc550d1e010de81
Default Engines Hash    : 4bc8b6e1b66cb932731fb1bdbbc550d1e010de81
Studio                  : 0.484.0
@MansurAliKoroglu MansurAliKoroglu added the kind/bug A reported bug. label Jul 1, 2023
@Jolg42 Jolg42 added team/client Issue for team Client. topic: enum "type"/block `enum` bug/1-unconfirmed Bug should have enough information for reproduction, but confirmation has not happened yet. tech/typescript Issue for tech TypeScript. topic: type-clash labels Jul 3, 2023
@Jolg42
Copy link
Member

Jolg42 commented Jul 3, 2023

This looks like a type clash with the Prisma Client enum "LogLevel" to me.

So renaming your enum name is the current workaround until we fix this.

Note that you could keep the original name in the database if you need to like this

enum Level {
  INFO
  WARN
  @@map("LogLevel")
}

Related to #12469

@SevInf SevInf changed the title Generated enum type is different when model name changes LogLevel enum conflicts with built-in Prisma type Jul 3, 2023
SevInf added a commit that referenced this issue Jul 12, 2023
Follow up to #20150.
Changes we did to extensions have fixed name clashes for models, but not
for enums. Enums problem is more complicated: in case of name clash, it
is impossible for contents of `Prisma` namespace to reference the value
from outer scope.
Solution is: all top-level enums are put into $Enums namespace. Types
within `Prisma` namespace always refer to them using fully-qualifed
name. Top-level enums are re-exported from `$Enums` namespace for
backward compatiblity.

Also, does opportunistic clean-ups/refactors

Fix #20031
@Jolg42 Jolg42 added bug/2-confirmed Bug has been reproduced and confirmed. and removed bug/1-unconfirmed Bug should have enough information for reproduction, but confirmation has not happened yet. labels Jul 13, 2023
@Jolg42 Jolg42 added this to the 5.1.0 milestone Jul 13, 2023
SevInf added a commit that referenced this issue Jul 18, 2023
Follow up to #20150.
Changes we did to extensions have fixed name clashes for models, but not
for enums. Enums problem is more complicated: in case of name clash, it
is impossible for contents of `Prisma` namespace to reference the value
from outer scope.
Solution is: all top-level enums are put into $Enums namespace. Types
within `Prisma` namespace always refer to them using fully-qualifed
name. Top-level enums are re-exported from `$Enums` namespace for
backward compatiblity.

Also, does opportunistic clean-ups/refactors

Fix #20031
SevInf added a commit that referenced this issue Jul 19, 2023
* fix(client): Enum type clashes

Follow up to #20150.
Changes we did to extensions have fixed name clashes for models, but not
for enums. Enums problem is more complicated: in case of name clash, it
is impossible for contents of `Prisma` namespace to reference the value
from outer scope.
Solution is: all top-level enums are put into $Enums namespace. Types
within `Prisma` namespace always refer to them using fully-qualifed
name. Top-level enums are re-exported from `$Enums` namespace for
backward compatiblity.

Also, does opportunistic clean-ups/refactors

Fix #20031

* No enums on SQL Server, duh!

* Update snapshots
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug/2-confirmed Bug has been reproduced and confirmed. kind/bug A reported bug. team/client Issue for team Client. tech/typescript Issue for tech TypeScript. topic: enum "type"/block `enum` topic: type-clash
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants