https://www.prisma.io/ logo
Join Slack
Powered by
```BookingToModeratorParticipant (Relation) - The ...
# orm-help
i
Copy code
BookingToModeratorParticipant (Relation)
- The id column `id` in link table `_BookingToModeratorParticipant` has been removed.
It was a Prisma legacy column that is not in use anymore.


Applying changes... (0/252)
Applying changes... (33/252)
Applying changes... (87/252)
Applying changes... (102/252)
Applying changes... (121/252)
Applying changes... 26.0s
���    The Migration failed and has not been performed. This is very likely not a
���    transient issue.
���    org.postgresql.util.PSQLException: ERROR: column "id" of relation
���    "_NotificationParamsToPurchasedService" does not exist
After migrating from the old datamodel in prisma1@1.30.5 to prisma1@1.34.12 I’m getting this error. I have verified in psql that the ids for all relations are in fact gone. So, the deploy did work the first time (and there were no errors the first time I deployed). So, I’m not sure why prisma now shows this id column removal notice for every relation and then subsequent error stating that it can’t find the id column on one of them. I’m not querying the id column of any relation anywhere explicitly. This happens on every prisma deploy when my app starts now. Any ideas?
I’m getting many runtime errors now as well in my prisma service logs: “column \“id\” of relation \“_UserLoginAttempt\” does not exist\n Position:” Any idea why this is still looking for relation table ids even though the datamodel has been updated to remove them?
Is prisma-binding compatible with the new datamodel structure?
any ideas @Ryan? We recently updated our prisma-binding prisma1 project to the latest graphql-cli version v4. Could that be causing issues? The error above causes the deploy to fail and rollback every time as per the prisma logs.
When I try to deploy with just prisma1 deploy (without --force) it says I have not migrated from the old model yet
I’m getting this error in the prisma logs as the very first error:
Copy code
{"key":"error/handled","requestId":"local:cksosu6qv008a0e031mr4sxep","payload":{"exception":"com.prisma.deploy.schema.InvalidToken: Authentication token is invalid: 'Authorization' header not provided","query":"{\n        listProjects {\n          name\n        }\n
[Debug] Initializing deployment worker for api$stag
[Debug] Scheduling deployment for project api$stag
Encountered exception while applying migration. Rolling back. org.postgresql.util.PSQLException: ERROR: column "id" of relation "_NotificationParamsToPurchasedService" does not exist
org.postgresql.util.PSQLException: ERROR: column "id" of relation "_NotificationParamsToPurchasedService" does not exist
My prisma compose config includes the management api secret and so do the environments for prisma and my server container. I’ve had this working for years with the same api management secret. The only difference now is the new datamodel. How could updating the datamodel invalidate my management api secret?
@Ryan Sorry to tag again, I’m just desperate because we need this datamodel update and this error has stopped our production code from moving.
It says the deploy failed and that it rolled back, however in psql everything appears to have migrated. (i.e all relations have the id columns removed) I’m also now having issues with prisma.mutation.updateUser whereby it says that createdAt does not exist on it despite it being clearly on the datamodel and in the User table in psql after the deploy.
@Ryan It looks like the SQL command that ran the ALTER TABLE to drop the id column does not include the IF EXISTS which is causing the id drop to throw an error and stop the deploy. Perhaps the code is running
Copy code
ALTER TABLE "example$example"."_ExampleToOtherExample" DROP COLUMN "id"
when it should be running:
Copy code
ALTER TABLE "example$example"."_ExampleToOtherExample" DROP COLUMN IF EXISTS "id"
This prevents errors from being thrown if it already deleted something.
I couldn’t find any such drop column command I found this in your codebase for prisma1 in prisma1/server/connectors/deploy-connector-jdbc/src/main/scala/com/prisma/deploy/connector/jdbc/database/JdbcDeployDatabaseMutationBuilder.scala:
Copy code
def addOrRemoveIdColumn(project: Project, previousRelation: Relation, nextRelation: Relation): DBIO[_] = {
    (previousRelation.idColumn, nextRelation.idColumn) match {
      case (Some(idColumn), None) => deleteColumn(project, previousRelation.relationTableName, idColumn)
      case (None, Some(idColumn)) =>
        // We are not adding a primary key column because we don't need it actually.
        // Because of the default this column will also work if the insert does not contain the id column.
        val query = sql.alterTable(name(project.dbName, previousRelation.relationTableName)).addColumn(field(s""""#$idColumn" varchar(40) default null"""))

        changeDatabaseQueryToDBIO(query)()
      case _ => DBIO.successful(())
    }
  }
However, it looks like it should be resilient to columns not existing.
So, I was able to solve this by: 1. exporting the database that was on the old datamodel 2. wiping my postgres volume (assigning a new empty volume in this case) 3. running prisma and postgres containers to initialize them 4. deploying the new datamodel to the newly initialized database 5. importing the old data backup into the new database with the new datamodel already in place
3 Views
Open in Slack
PreviousNext
Powered by