Prisma 4.6.0 drops and recreates enum field when running db push even if the field has not changed #16180

alexisbellido · 2022-11-08T19:45:14Z

Bug description

I just updated from Prisma 4.5.0 to 4.6.0 and now every time I run npx prisma db push, even if I haven't changed anything in schema.prisma, Prisma wants to drop and recreate an enum field. I get this message:

The `roles` column on the `User` table would be dropped and recreated. This will lead to data loss

If I choose to ignore the warning all my data in the roles column is reset.

After testing with multiple changes to my schema and simplifying it to the most basic form (included below) I downgraded to Prisma 4.5.0 and everything works as expected there. I've reconfirmed the problem exists by going back to Prisma 4.6.0.

How to reproduce

Use the provided basic schema.prisma. Pay attention to the roles field, which is an enum.
Create at least one row in the user table containing a value for the roles field.
Run npx prisma db push multiple times without changing anything in schema.prisma.
You will see The rolescolumn on theUser table would be dropped and recreated. This will lead to data loss, and if you accept the warning the data in the roles column will be reset.

Expected behavior

The roles enum column is not being changed in schema.prisma so it shouldn't be dropped and recreated when running npx prisma db push.

Prisma information

model User {
  id                    Int               @id @default(autoincrement())
  username              String            @unique @db.VarChar(32)
  roles                 Role[]            @default([COLLECTOR])
}

enum Role {
  ADMIN
  COLLECTOR
}

// Add your code using Prisma Client

Environment & setup

OS: Ubuntu Linux
Database: PostgreSQL 14.2
Node.js version: 18.0.0

Prisma Version

4.6.0

The text was updated successfully, but these errors were encountered:

bsproul · 2022-11-08T21:29:27Z

Seeing the same behavior here, when we run our diff in CI, we see a number of hits that are not expected, all related to enums:

Run npx prisma migrate diff --from-schema-datamodel ./prisma/schema.prisma --to-url "$DATABASE_URL" --exit-code

[+] Added enums
  - user_status
  - user_status_reason_code

[-] Removed enums
  - UserStatus
  - UserStatusReasonCode


[*] Changed the `user` table
  [*] Column `status` would be dropped and recreated (type changed)
  [*] Column `status_reason_code` would be dropped and recreated (type changed)
  [*] Column `preferred_mfa_method` would be dropped and recreated (type changed)

All of these have @@Map set:

enum UserStatus {
  ACTIVE
  @@map("user_status")
}

davidlumley · 2022-11-09T06:14:26Z

Running into the same issue with a similar schema, looks like 4.6.0 might be ignoring the @@map directive:

enum NotificationEntityType {
  buy_order
  sell_order
  product_update

  @@map("notification_entity_type")
}

Resulting migration looks like this:

-- CreateEnum
CREATE TYPE "NotificationEntityType" AS ENUM ('buy_order', 'sell_order', 'product_update');

-- DropEnum
DROP TYPE "notification_entity_type";

I was able to reproduce this by:

having a database state created previous to 4.6.0
running prisma migrate dev to generate an unrelated migration

@Map

When calculating a SQL schema from a Prisma schema, the Postgres connector of the migration engine would use the name of the enum instead of its database name (see parser-database docs for the reference on what these mean). To picture this with an example, the following schema. ``` enum PersonType { Dog Cat @@Map("pet_preference") } ``` would correspond, before the regression, and after this commit, to: ``` CREATE TYPE "pet_preference" AS ENUM ('Dog', 'Cat'); ``` but the regression caused it to correspond to: ``` CREATE TYPE "PersonType" AS ENUM ('Dog', 'Cat'); ``` This does not only affect newly created enums: we diff the wrong enums, causing bad migrations for existing users of Migrate that have the enums with the correct (mapped) names in their database. Users reported the regression in prisma/prisma#16180 This commit should completely fix the problem. The regression was introduced in an unrelated refactoring in b6400f1. Enum names in column types were replace with enum ids — a win for correctness. As part of this refactoring, the `sql_schema_describer::Enum` type was made private, and adding enums to a schema became possible only through `SqlSchema::push_enum`. In the SQL migration connector What could have caught this: - Testing that the name of the database enum in the migration is the mapped name. We can test this: - Through `.assert_schema()`, which has existed for a long time. It is a gap in our test coverage that we weren't testing this. - The new single migration tests, like the test in this commit. They are new, and they are less work than the previous option. - migrations-ci could have caught this, but it is currently neglected.

tomhoule · 2022-11-09T08:11:16Z

Hi there 👋 Quick update from the Prisma folks: we are working on this. There is indeed a regression with enums in 4.6.0, and here's a PR to fix it prisma/prisma-engines#3368

The bug appears when the following two conditions are met:

Provider is postgresql or cockroachdb
You use @@map on enums.

The regression is that we started using the name of the enum instead of the mapped name (more details in the PR). This is a very embarassing gap in our tests.

If you experience a regression with db push or migrate dev or migrate diff in 4.6.0 outside of the two conditions named above, please post here with as much detail as possible, because you are experiencing a different regression that will not be fixed by the PR in this comment.

tomhoule · 2022-11-09T08:13:29Z

@alexisbellido I tried reproducing first using your instructions and could not observe any bad behaviour. Can you try again and confirm if you can really observe undesirable migrations without @@map on the enum?

hoghweed · 2022-11-09T09:47:56Z

On my team, we have precisely the same behavior

tomhoule · 2022-11-09T09:52:03Z

@hoghweed the behaviour described by @alexisbellido (without @@map) or the behaviour described by @bsproul and @davidlumley ?

hoghweed · 2022-11-09T09:59:25Z

@hoghweed the behaviour described by @alexisbellido (without @@map) or the behaviour described by @bsproul and @davidlumley ?

The one without the @@map on the @enum

tomhoule · 2022-11-09T10:05:19Z

Ok that's concerning, we can't reproduce what @alexisbellido described, do you have more details that would help us reproduce the issue?

edit: thanks a lot for engaging btw

janpio · 2022-11-09T10:34:50Z

To make it explicit @hoghweed: We need your help to understand the case where an enum without @@map leads to migrations being created all the time. We can currently not reproduce ourselves.

hoghweed · 2022-11-09T10:43:10Z

@janpio I know that, unfortunately, as I was saying to Nikolas Burk on Twitter, unfortunately it is very hard to give a context to make this reproducible. Our schema is a simple one with enums, but I'm not sure what is context I can give you.

I can just tell you how we found the bug:

applied prisma update to 4.6.0
applied previous migrations to the underlying database in Test
it started to ask for what name to give to a new migration, that migration was including just enums columns already included in previous migrations (we didn't change those columns from weeks)
even if we create such a new migration, each time we've applied migrations to the database, Prisma has asked to create a new migration with the above enum columns
this could go ahead with no limit - only for testing it asked to create 3 times the same migration

This is the only context I can give without giving you the full schema
Ho this help

janpio · 2022-11-09T10:52:03Z

Can you run this command please?

npx prisma migrate diff --from-schema-datamodel ./prisma/schema.prisma --to-url "$DATABASE_URL" --exit-code

(make sure that DATABASE_URL is set before running this)

This should output something like #16180 (comment)

Can you then please also share the Prisma schema snippets that define these enums and the models around them? Thanks.

hoghweed · 2022-11-09T11:08:26Z

The command result is

[*] Changed the `Action` table
  [*] Column `result` would be dropped and recreated (type changed)

[*] Changed the `ActionLog` table
  [*] Column `kind` would be dropped and recreated (type changed)

This is the Prisma snippet.

enum Kind {
  info
  warning
  error
}

enum Result {
  succeeded
  failed
}

Consider we don't change those from 5 months, the only change made to the tables was just an indentation change.

tomhoule · 2022-11-09T11:08:51Z

Thanks! We'll try to dig deeper.

@Map

* me: fix regression w/ mapped enum names on postgres When calculating a SQL schema from a Prisma schema, the Postgres connector of the migration engine would use the name of the enum instead of its database name (see parser-database docs for the reference on what these mean). To picture this with an example, the following schema. ``` enum PersonType { Dog Cat @@Map("pet_preference") } ``` would correspond, before the regression, and after this commit, to: ``` CREATE TYPE "pet_preference" AS ENUM ('Dog', 'Cat'); ``` but the regression caused it to correspond to: ``` CREATE TYPE "PersonType" AS ENUM ('Dog', 'Cat'); ``` This does not only affect newly created enums: we diff the wrong enums, causing bad migrations for existing users of Migrate that have the enums with the correct (mapped) names in their database. Users reported the regression in prisma/prisma#16180 This commit should completely fix the problem. The regression was introduced in an unrelated refactoring in b6400f1. Enum names in column types were replace with enum ids — a win for correctness. As part of this refactoring, the `sql_schema_describer::Enum` type was made private, and adding enums to a schema became possible only through `SqlSchema::push_enum`. In the SQL migration connector What could have caught this: - Testing that the name of the database enum in the migration is the mapped name. We can test this: - Through `.assert_schema()`, which has existed for a long time. It is a gap in our test coverage that we weren't testing this. - The new single migration tests, like the test in this commit. They are new, and they are less work than the previous option. - migrations-ci could have caught this, but it is currently neglected. * me: move enum test to enums directory

janpio · 2022-11-09T11:45:14Z

Thanks indeed @hoghweed.

What database are you using (make and version)?
What do the models look like where you use those enums?
Anything "happening" with these enums or the fields using them? (index, relation, or anything else besides just cleanly using them as the type for a field)

Can you maybe share your schema file privately with us at schemas@prisma.io? (Happy to sign NDA if necessary)

tomhoule · 2022-11-09T11:45:49Z

(the few last migrations would also be helpful clues)

Jolg42 · 2022-11-09T11:59:47Z

Notes
I tried the reproductions steps from the description, using Prisma version 4.6.0 and postgres:14.2 docker image but could not reproduce the issue.
For the data I used

INSERT INTO "public"."User" ("username", "roles") VALUES ('someusername', '{COLLECTOR}');

tomhoule · 2022-11-09T12:27:39Z

Quick update on this: we think we have a reproduction for the second problem, we're confirming that and working on a PR.

This regression was reported by users in prisma/prisma#16180 It was introduced on b6400f1 by the same change that caused the _other_ regression that was fixed in eb39236. In that refactoring, we started storing enum ids instead of enum names in `ColumnTypeFamily::Enum(_)`. That makes the `ColumntypeFamily` type smaller, easier to deal with with regards to ownership (`EnumId` is `Copy`), and ready for multi-schema, because the name can be ambiguous and does not carry schema information, whereas the `EnumId` does. But more relevant to this commit: it makes comparing two `ColumnTypeFamily` inaccurate _when the types come from two different schemas_, like in sql_schema_differ. That in turn changed the signature of `column_type_family_as_enum()`, leading to the differ comparing enum ids instead of enum names, which directly causes the false positives in diffing, because the same enum has a different ID in each of the two schemas. The code that caused the regression does not appear in b6400f1, it uses code that was changed there. This is also a problem with the generated implementation of PartialEq for ColumnTypeFamily. Since it would be a larger refactoring, we only deal with this where relevant (sql_schema_differ) and leave removing the dangerous PartialEq implementation to another PR. This is the issue: #3373. How could this have been caught? - Tests that check that migrations are idempotent with multiple enums, all used in model columns _not defined in alphabetical order_ (sad but true). - This is chiming with the theme of us not testing with large enough Prisma Schemas. - migrations-ci could have caught this. We are neglecting it at the moment.

This regression was reported by users in prisma/prisma#16180 It was introduced on b6400f1 by the same change that caused the _other_ regression that was fixed in eb39236. Symptoms: enum migrations became non-idempotent in many cases, depending on the ordering of the migrations in the Prisma schema. In that refactoring, we started storing enum ids instead of enum names in `ColumnTypeFamily::Enum(_)`. That makes the `ColumntypeFamily` type smaller, easier to deal with with regards to ownership (`EnumId` is `Copy`), and ready for multi-schema, because the name can be ambiguous and does not carry schema information, whereas the `EnumId` does. But more relevant to this commit: it makes comparing two `ColumnTypeFamily` inaccurate _when the types come from two different schemas_, like in sql_schema_differ. That in turn changed the signature of `column_type_family_as_enum()`, leading to the differ comparing enum ids instead of enum names, which directly causes the false positives in diffing, because the same enum has a different ID in each of the two schemas. The code that caused the regression does not appear in b6400f1, it uses code that was changed there. This is also a problem with the generated implementation of PartialEq for ColumnTypeFamily. Since it would be a larger refactoring, we only deal with this where relevant (sql_schema_differ) and leave removing the dangerous PartialEq implementation to another PR. This is the issue: #3373. How could this have been caught? - Tests that check that migrations are idempotent with multiple enums, all used in model columns _not defined in alphabetical order_ (sad but true). - This chimes with the theme of us not testing with large enough Prisma schemas. - migrations-ci could have caught this. We are neglecting it at the moment.

alexisbellido · 2022-11-09T15:21:24Z

Hi, I can reproduce with the steps and schema in my original description and Prisma 4.6.0. As you can see from my basic schema I'm not using @@Map at all. But from what I've read it looks like a few others have experienced the same issue.

Thank you for looking into this.

Jolg42 · 2022-11-09T15:54:23Z

We will prepare a patch release tomorrow.
We'll keep you updated as soon as it's available.

jameyhart · 2022-11-09T16:03:55Z

Hi @janpio,
We're experiencing the same issue here at Jisc.

We'll provide the details you asked for above.

Database: Postgres v12.8
Models: We use various enums across our database but here is an example:-

model Account {
    id                     String              @id @default(cuid())
    name                   String
    type                   AccountType         @default(TRIAL)
    sector                 Sector?
    ...
}

model SurveyReport {
    id                String       @id @default(cuid())
    surveyId          String
    survey            Survey       @relation(fields: [surveyId], references: [id], onDelete: SetNull)
    reportType        SurveyReportType
    ...
}

enum AccountType {
    ORGANISATION
    TRIAL
    ...
}

enum Sector {
    PRIVATE_SECTOR
    PUBLIC_SECTOR
    ...
}

enum SurveyReportType {
    SPAM
    OTHER
    ...
}

We were creating a new migration based off the latest Prisma validation error:

Here is a screenshot of the diff between the changes we tried to make:

This ultimately resulted in a migration file, which attempted to drop rows within other models that referenced enums.

Interestingly, the migration file created on v4.6.0 attempts to drop rows that reference the enum SECTOR, which happens to be optional.
However, does not make any changes to the AccountType, which is a required field and has a default value set.

@Map

* me: fix regression w/ mapped enum names on postgres When calculating a SQL schema from a Prisma schema, the Postgres connector of the migration engine would use the name of the enum instead of its database name (see parser-database docs for the reference on what these mean). To picture this with an example, the following schema. ``` enum PersonType { Dog Cat @@Map("pet_preference") } ``` would correspond, before the regression, and after this commit, to: ``` CREATE TYPE "pet_preference" AS ENUM ('Dog', 'Cat'); ``` but the regression caused it to correspond to: ``` CREATE TYPE "PersonType" AS ENUM ('Dog', 'Cat'); ``` This does not only affect newly created enums: we diff the wrong enums, causing bad migrations for existing users of Migrate that have the enums with the correct (mapped) names in their database. Users reported the regression in prisma/prisma#16180 This commit should completely fix the problem. The regression was introduced in an unrelated refactoring in b6400f1. Enum names in column types were replace with enum ids — a win for correctness. As part of this refactoring, the `sql_schema_describer::Enum` type was made private, and adding enums to a schema became possible only through `SqlSchema::push_enum`. In the SQL migration connector What could have caught this: - Testing that the name of the database enum in the migration is the mapped name. We can test this: - Through `.assert_schema()`, which has existed for a long time. It is a gap in our test coverage that we weren't testing this. - The new single migration tests, like the test in this commit. They are new, and they are less work than the previous option. - migrations-ci could have caught this, but it is currently neglected. * me: move enum test to enums directory

This regression was reported by users in prisma/prisma#16180 It was introduced on b6400f1 by the same change that caused the _other_ regression that was fixed in eb39236. Symptoms: enum migrations became non-idempotent in many cases, depending on the ordering of the migrations in the Prisma schema. In that refactoring, we started storing enum ids instead of enum names in `ColumnTypeFamily::Enum(_)`. That makes the `ColumntypeFamily` type smaller, easier to deal with with regards to ownership (`EnumId` is `Copy`), and ready for multi-schema, because the name can be ambiguous and does not carry schema information, whereas the `EnumId` does. But more relevant to this commit: it makes comparing two `ColumnTypeFamily` inaccurate _when the types come from two different schemas_, like in sql_schema_differ. That in turn changed the signature of `column_type_family_as_enum()`, leading to the differ comparing enum ids instead of enum names, which directly causes the false positives in diffing, because the same enum has a different ID in each of the two schemas. The code that caused the regression does not appear in b6400f1, it uses code that was changed there. This is also a problem with the generated implementation of PartialEq for ColumnTypeFamily. Since it would be a larger refactoring, we only deal with this where relevant (sql_schema_differ) and leave removing the dangerous PartialEq implementation to another PR. This is the issue: #3373. How could this have been caught? - Tests that check that migrations are idempotent with multiple enums, all used in model columns _not defined in alphabetical order_ (sad but true). - This chimes with the theme of us not testing with large enough Prisma schemas. - migrations-ci could have caught this. We are neglecting it at the moment.

alexisbellido · 2022-11-09T16:18:35Z

Hey, @tomhoule,

I couldn't replicate the original issue with the sample schema I provided (without @@map) so I gradually re-added the other fields and models from my application and I could reproduce it.

Here's the basic schema to try.

model User {
  id                    Int               @id @default(autoincrement())
  username              String            @unique @db.VarChar(32)
  roles                 Role[]            @default([COLLECTOR])
  nfts                  NFT[]
}

enum Role {
  ADMIN
  COLLECTOR
}

model NFT {
  id            Int           @id @default(autoincrement())
  owner         User          @relation(fields: [ownerId], references: [id])
  ownerId       Int           @unique
  images        NFTImage[]
}

model NFTImage {
  id           Int              @id @default(autoincrement())
  nft          NFT              @relation(fields: [nftId], references: [id])
  nftId        Int
  title        String?          @db.VarChar(64)
  src          String?          @db.VarChar(128) // URL pointing to image
  alt          String?          @db.VarChar(64)
  orientation  ImageOrientation @default(VERTICAL)
}

enum ImageOrientation {
  HORIZONTAL
  VERTICAL
}

Then reset with this.

npx prisma db push --force-reset

and insert one row to the User table.

INSERT INTO "User" (username, roles) VALUES ('someusername', '{COLLECTOR, ADMIN}');

now, and without changing anything else, run npx prisma db push and you will see Prisma trying to drop and recreate the roles column.

Here's my output from npx prisma migrate diff --from-schema-datamodel ./prisma/schema.prisma --to-url "$DATABASE_URL" --exit-code.

[*] Changed the `NFTImage` table
  [*] Column `orientation` would be dropped and recreated (type changed)

[*] Changed the `User` table
  [*] Column `roles` would be dropped and recreated (type changed)

I think I started seeing the problem again when I added the relations between User, NFT and NFTImage (which has its own enum for the orientation column. I wonder if the two enum columns in different models (roles and orientation) may be confusing the engine.

Jolg42 · 2022-11-09T16:37:10Z

Thanks @alexisbellido
I can reproduce on 4.6.0
After inserting one row I get the following for npx prisma db push

Environment variables loaded from prisma/.env
Prisma schema loaded from prisma/schema.prisma
Datasource "db": PostgreSQL database "16180", schema "public" at "localhost:5432"

⚠️  There might be data loss when applying the changes:

  • The `roles` column on the `User` table would be dropped and recreated. This will lead to data loss.

? Do you want to ignore the warning(s)? › (y/N)

and for npx prisma migrate diff --from-schema-datamodel ./prisma/schema.prisma --to-url "$DATABASE_URL" --exit-code prints the same
The SQL when adding --script:

-- AlterTable
ALTER TABLE "User" DROP COLUMN "roles",
ADD COLUMN     "roles" "Role"[] DEFAULT ARRAY['COLLECTOR']::"Role"[];

-- AlterTable
ALTER TABLE "NFTImage" DROP COLUMN "orientation",
ADD COLUMN     "orientation" "ImageOrientation" NOT NULL DEFAULT 'VERTICAL';

This does not happen on 4.5.0.

tomhoule · 2022-11-09T16:42:08Z

Hi @alexisbellido — I confirmed in a test with your example schema that prisma/prisma-engines@b4992e9 fixes the issue. Stay tuned for the patch release.

janpio · 2022-11-09T17:43:25Z

@jameyhart It seems to me you are experiencing two things here at the same time: We changed our validations around SetNull - and then when you try to fix that, you hit the problem that is discussed in this thread. Can you please open a new issue for the SetNull change? I will want to discuss that with you and ask a few follow up questions. Thanks!

rcbevans · 2022-11-09T21:39:07Z

Came here looking for this because I just bumped to 4.6 to get Postgres native upserts (yay!) but now I'm seeing the same issue with Prisma attempting to drop and recreate all enum fields after trying to add a new migration to our schema. Glad it's already on the radar with a fix pending.

rcbevans · 2022-11-09T21:47:19Z

Hi there wave Quick update from the Prisma folks: we are working on this. There is indeed a regression with enums in 4.6.0, and here's a PR to fix it prisma/prisma-engines#3368

The bug appears when the following two conditions are met:
1. Provider is `postgresql` or `cockroachdb`

2. You use `@@map` on enums.
The regression is that we started using the name of the enum instead of the mapped name (more details in the PR). This is a very embarassing gap in our tests.

If you experience a regression with db push or migrate dev or migrate diff in 4.6.0 outside of the two conditions named above, please post here with as much detail as possible, because you are experiencing a different regression that will not be fixed by the PR in this comment.

Is this comment still applicable, I do not have @@map in my schema, and am hitting this issue with 4.6.0.

alexisbellido · 2022-11-09T22:16:05Z

Hello, @rcbevans , I'm not using @@map either so I think we're experiening similar problems and a few comments above @tomhoule confirmed the patch fixes it.

rcbevans · 2022-11-09T22:32:47Z

Thanks @alexisbellido. Fingers crossed it's the same underlying issue and 4.7 will resolve the issue for us also. Thankfully I caught this before any of the team made any schema changes.

Jolg42 · 2022-11-09T22:56:30Z

@alexisbellido @rcbevans @bsproul @hoghweed @davidlumley
Could you try to update prisma and @prisma/client to the 4.6.1-dev.1 internal patch version that includes the fixes and let us know if that solves your issue?

We will wait for some confirmations before we publish the official patch to latest.

jansedlon · 2022-11-10T08:48:10Z

@Jolg42 4.6.1-dev.1 fixed it for me

alexisbellido · 2022-11-10T15:07:52Z

@Jolg42 , I just tested 4.6.1-dev.1 and it fixes the issue for me too.

Thank you so much, Prisma team.

Jolg42 · 2022-11-10T15:09:57Z

The official patch is out in 4.6.1

Update Prisma from `4.6.0` to `4.6.1` to solve enum issue with PostgreSQL prisma/prisma#16180

See prisma/prisma#16180

Update Prisma from `4.6.0` to `4.6.1` to solve enum issue with PostgreSQL prisma/prisma#16180

alexisbellido added the kind/bug A reported bug. label Nov 8, 2022

janpio added bug/1-unconfirmed Bug should have enough information for reproduction, but confirmation has not happened yet. team/schema Issue for team Schema. topic: enum "type"/block `enum` topic: prisma db push CLI: prisma db push labels Nov 8, 2022

tomhoule self-assigned this Nov 9, 2022

tomhoule mentioned this issue Nov 9, 2022

me: fix regression w/ mapped enum names on postgres prisma/prisma-engines#3368

Merged

Jolg42 added this to the 4.7.0 milestone Nov 9, 2022

tomhoule mentioned this issue Nov 9, 2022

me: fix regression in enum column type diffing prisma/prisma-engines#3374

Merged

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 Nov 9, 2022

alexisbellido mentioned this issue Nov 9, 2022

@@map not working on postgress enums starting version 4.6.0 #16209

Closed

Jolg42 mentioned this issue Nov 10, 2022

What happen with prisma migrate dev #16220

Closed

Jolg42 closed this as completed Nov 10, 2022

Jolg42 mentioned this issue Nov 10, 2022

Prisma complains when enum types are not declared in alphabetical order #16225

Closed

tordans added a commit to tordans/blitz that referenced this issue Jan 18, 2023

Update to "prisma": "4.6.1"

e49611a

Update Prisma from `4.6.0` to `4.6.1` to solve enum issue with PostgreSQL prisma/prisma#16180

tordans mentioned this issue Jan 18, 2023

Update to "prisma": "4.6.1" blitz-js/blitz#4062

Merged

1 task

tordans added a commit to FixMyBerlin/trassenscout that referenced this issue Jan 18, 2023

Update Prisma to 4.6.1 to solve enum error

277d67c

See prisma/prisma#16180

tordans added a commit to tordans/blitz that referenced this issue Feb 7, 2023

Update to "prisma": "4.6.1"

5dd4f17

Update Prisma from `4.6.0` to `4.6.1` to solve enum issue with PostgreSQL prisma/prisma#16180

github-actions bot mentioned this issue Feb 13, 2023

Version Packages (beta) blitz-js/blitz#4083

Merged

github-actions bot mentioned this issue Mar 3, 2023

Version Packages (beta) siddhsuresh/blitz#65

Open

devunt mentioned this issue Dec 18, 2023

Prisma drops and recreates enum array field when running migrate even if the field has not changed #22456

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Prisma 4.6.0 drops and recreates enum field when running db push even if the field has not changed #16180

Prisma 4.6.0 drops and recreates enum field when running db push even if the field has not changed #16180

alexisbellido commented Nov 8, 2022 •

edited by janpio

bsproul commented Nov 8, 2022 •

edited

davidlumley commented Nov 9, 2022 •

edited

tomhoule commented Nov 9, 2022

tomhoule commented Nov 9, 2022 •

edited by janpio

hoghweed commented Nov 9, 2022

tomhoule commented Nov 9, 2022

hoghweed commented Nov 9, 2022

tomhoule commented Nov 9, 2022 •

edited

janpio commented Nov 9, 2022

hoghweed commented Nov 9, 2022

janpio commented Nov 9, 2022

hoghweed commented Nov 9, 2022

tomhoule commented Nov 9, 2022

janpio commented Nov 9, 2022

tomhoule commented Nov 9, 2022

Jolg42 commented Nov 9, 2022

tomhoule commented Nov 9, 2022

alexisbellido commented Nov 9, 2022 •

edited

Jolg42 commented Nov 9, 2022

jameyhart commented Nov 9, 2022

alexisbellido commented Nov 9, 2022 •

edited by janpio

Jolg42 commented Nov 9, 2022

tomhoule commented Nov 9, 2022

janpio commented Nov 9, 2022

rcbevans commented Nov 9, 2022

rcbevans commented Nov 9, 2022 •

edited by janpio

alexisbellido commented Nov 9, 2022 •

edited by janpio

rcbevans commented Nov 9, 2022

Jolg42 commented Nov 9, 2022

jansedlon commented Nov 10, 2022

alexisbellido commented Nov 10, 2022

Jolg42 commented Nov 10, 2022

Prisma 4.6.0 drops and recreates enum field when running db push even if the field has not changed #16180

Prisma 4.6.0 drops and recreates enum field when running db push even if the field has not changed #16180

Comments

alexisbellido commented Nov 8, 2022 • edited by janpio

Bug description

How to reproduce

Expected behavior

Prisma information

Environment & setup

Prisma Version

bsproul commented Nov 8, 2022 • edited

davidlumley commented Nov 9, 2022 • edited

tomhoule commented Nov 9, 2022

tomhoule commented Nov 9, 2022 • edited by janpio

hoghweed commented Nov 9, 2022

tomhoule commented Nov 9, 2022

hoghweed commented Nov 9, 2022

tomhoule commented Nov 9, 2022 • edited

janpio commented Nov 9, 2022

hoghweed commented Nov 9, 2022

janpio commented Nov 9, 2022

hoghweed commented Nov 9, 2022

tomhoule commented Nov 9, 2022

janpio commented Nov 9, 2022

tomhoule commented Nov 9, 2022

Jolg42 commented Nov 9, 2022

tomhoule commented Nov 9, 2022

alexisbellido commented Nov 9, 2022 • edited

Jolg42 commented Nov 9, 2022

jameyhart commented Nov 9, 2022

alexisbellido commented Nov 9, 2022 • edited by janpio

Jolg42 commented Nov 9, 2022

tomhoule commented Nov 9, 2022

janpio commented Nov 9, 2022

rcbevans commented Nov 9, 2022

rcbevans commented Nov 9, 2022 • edited by janpio

alexisbellido commented Nov 9, 2022 • edited by janpio

rcbevans commented Nov 9, 2022

Jolg42 commented Nov 9, 2022

jansedlon commented Nov 10, 2022

alexisbellido commented Nov 10, 2022

Jolg42 commented Nov 10, 2022

alexisbellido commented Nov 8, 2022 •

edited by janpio

bsproul commented Nov 8, 2022 •

edited

davidlumley commented Nov 9, 2022 •

edited

tomhoule commented Nov 9, 2022 •

edited by janpio

tomhoule commented Nov 9, 2022 •

edited

alexisbellido commented Nov 9, 2022 •

edited

alexisbellido commented Nov 9, 2022 •

edited by janpio

rcbevans commented Nov 9, 2022 •

edited by janpio

alexisbellido commented Nov 9, 2022 •

edited by janpio