Prisma1: Deploying specific datamodel with a field of type UUID is stuck

[marktani]

Describe the bug
Deploying a new service with this datamodel is stuck on Applying changes:

enum Status {
  WIP
  COMPLETED
}
enum Role {
  USER,
  ADMIN
}
type User {
  id: UUID! @unique
  discord_id: String!
  username: String!
  email: String!
  # from discord
  picture: String!
  creations: [Creation!]!
  role: Role!
}
type Creation {
  id: UUID! @unique
  likes: Int!
  name: String!
  description: String!
  status: Status!
  # user uploads
  pictures: [File!]! @relation(name: "CreationPictures")
  file: File @relation(name: "CreationFile")
  tags: [String!]!
  creator: User!
}
type File {
  id: UUID! @unique
  name: String!
  url: String!
}

To Reproduce

1. npm install [email protected] -g
2. prisma init
3. Choose "Create new database"
4. docker-compose up -d
5. Use the above datamodel and prisma deploy

Output:

Applying changes... (0/33)  client Sending query to cluster local +6ms
  client http://localhost:4466/management +0ms
  client query ($name: String! $stage: String!) {
  client           migrationStatus(name: $name stage: $stage) {
  client             projectId
  client             revision
  client             status
  client             applied
  client             rolledBack
  client             errors
  client           }
  client         }
  client          +0ms
  client { stage: 'test', name: 'r-uuid-deploy' } +0ms
  client { migrationStatus:
  client    { rolledBack: 0,
  client      applied: 0,
  client      projectId: 'r-uuid-deploy$test',
  client      errors: [],
  client      revision: 2,
  client      status: 'IN_PROGRESS' } } +81ms
  client Sending query to cluster local +504ms
  client http://localhost:4466/management +0ms
  client query ($name: String! $stage: String!) {
  client           migrationStatus(name: $name stage: $stage) {
  client             projectId
  client             revision
  client             status
  client             applied
  client             rolledBack
  client             errors
  client           }
  client         }
  client          +0ms
  client { stage: 'test', name: 'r-uuid-deploy' } +0ms
  client { migrationStatus:
  client    { rolledBack: 0,
  client      applied: 0,
  client      projectId: 'r-uuid-deploy$test',
  client      errors: [],
  client      revision: 1,
  client      status: 'SUCCESS' } } +35ms
  client Sending query to cluster local +502ms
  client http://localhost:4466/management +0ms
  client query ($name: String! $stage: String!) {
  client           migrationStatus(name: $name stage: $stage) {
  client             projectId
  client             revision
  client             status
  client             applied
  client             rolledBack
  client             errors
  client           }
  client         }
  client          +0ms
  client { stage: 'test', name: 'r-uuid-deploy' } +0ms
  client { migrationStatus:
  client    { rolledBack: 0,
  client      applied: 0,
  client      projectId: 'r-uuid-deploy$test',
  client      errors: [],
  client      revision: 1,
  client      status: 'SUCCESS' } } +38ms
  client Sending query to cluster local +501ms
  client http://localhost:4466/management +0ms
  client query ($name: String! $stage: String!) {
  client           migrationStatus(name: $name stage: $stage) {
  client             projectId
  client             revision
  client             status
  client             applied
  client             rolledBack
  client             errors
  client           }
  client         }

Expected behavior
The deployment is not stuck and goes through.

Versions (please complete the following information):

• prisma CLI: prisma/1.12.0-beta.0 (darwin-x64) node-v10.4.1
• Prisma Server: 1.12-beta

Additional context

• This was reproduced using the Postgres connector.

• Changing

  type Creation {
  id: UUID! @unique
  

  to

  type Creation {
  id: ID! @unique
  

  works.

• Also note that File and User use id: UUID! @unique, and it always works for these types.

[my-name-is-nobody]

Having the same issue here w/ prismagraphql/prisma/1.12 docker & prisma/1.13.0 (windows-x64) node-v8.11.1

Culprit is the StringList (Creation.tags: [String!]!, in the example above) when used with a UUID-as-id type. Looking at the prisma server logs:

[Debug] Scheduling deployment for project project$dev
encountered exception while applying migration. will roll back. org.postgresql.util.PSQLException: ERROR: foreign key constraint "X_foo_nodeId_fkey" cannot be implemented
  Detail: Key columns "nodeId" and "id" are of incompatible types: character varying and uuid.
[Debug] Applied migration for project project$dev

Workflow as above + data model generating the log:

type X {
  id: UUID! @unique
  foo: [Int!]!
}

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[vadistic]

I tried to try a switch to UUID on postgress and faced the same error. Console is stuck on applying changes on smaller unit test schemas but it threw Error below on my bigger app.

CLI: prisma/1.16.2 (windows-x64) node-v10.10.0
Server: brand new ec2, Ubuntu 16.04 LTS, internal Postgres 10.5-1 & prisma:1.17-beta

Tested datamodel (type User does not work for me)

type User {
  id: UUID! @unique
}

// console
Applying changes !
 !    org.postgresql.util.PSQLException: ERROR: foreign key constraint "Candidate_emails_nodeId_fkey"
 !    cannot be implemented
 !    Detail: Key columns "nodeId" and "id" are of incompatible types: character varying and uuid.
 !    at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2433)
 !    at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:2178)
 !    at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:306)
 !    at org.postgresql.jdbc.PgStatement.executeInternal(PgStatement.java:441)
 !    at org.postgresql.jdbc.PgStatement.execute(PgStatement.java:365)
 !    at org.postgresql.jdbc.PgPreparedStatement.executeWithFlags(PgPreparedStatement.java:155)
 !    at org.postgresql.jdbc.PgPreparedStatement.execute(PgPreparedStatement.java:144)
 !    at com.zaxxer.hikari.pool.ProxyPreparedStatement.execute(ProxyPreparedStatement.java:44)
 !    at
 !    com.zaxxer.hikari.pool.HikariProxyPreparedStatement.execute(HikariProxyPreparedStatement.java)
 !    at slick.jdbc.StatementInvoker.results(StatementInvoker.scala:38)
 !    at slick.jdbc.StatementInvoker.iteratorTo(StatementInvoker.scala:21)
 !    at slick.jdbc.Invoker.first(Invoker.scala:30)
 !    at slick.jdbc.Invoker.first$(Invoker.scala:29)
 !    at slick.jdbc.StatementInvoker.first(StatementInvoker.scala:15)
 !    at slick.jdbc.StreamingInvokerAction$HeadAction.run(StreamingInvokerAction.scala:52)
 !    at slick.jdbc.StreamingInvokerAction$HeadAction.run(StreamingInvokerAction.scala:51)
 !    at slick.basic.BasicBackend$DatabaseDef$$anon$2.liftedTree1$1(BasicBackend.scala:275)
 !    at slick.basic.BasicBackend$DatabaseDef$$anon$2.run(BasicBackend.scala:275)
 !    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
 !    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
 !    at java.lang.Thread.run(Thread.java:748)
 !

// ssh
[Debug] Scheduling deployment for project project$dev
encountered exception while applying migration. will roll back. org.postgresql.util.PSQLException: ERROR: foreign key constraint "Candidate_emails_nodeId_fkey" cannot be implemented
  Detail: Key columns "nodeId" and "id" are of incompatible types: character varying and uuid.
[Debug] Applied migration for project project$dev

Is there maybe some recommended setup that would work?

[mavilein]

The problem is our implementation of scalar lists. Scalar lists are realized through a separate table that have foreign key to the table of the model itself. The foreign key is of type VARCHAR(25) but it tries to reference a column of type UUID. Therefore this error is thrown. With our current implementation we can't fix it. The solution is to implement native scalar lists that do not have this problem.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 10 days if no further activity occurs. Thank you for your contributions.

[Shion093]

Having the same issue with Prisma 1.28, using Postgres 10.6

this is my model

type DeviceModel {
  id: UUID! @unique
  name: String
  image: String
  identifier: String
  createdBy: User @relation(name: "DeviceModelUserCreated")
  updatedBy: User @relation(name: "DeviceModelUserUpdated")
  organization: Organization
  network: [String]
  launched: String
  dimensions: Dimensions
  display: Display
  os: String
  customOs: String
  chipset: String
  cpu: String
  gpu: String
  memory: Memory
  camera: [String]
  video: [String]
  sound: [String]
  communications: Comunications
}

and the error

The Migration failed and has not been performed. This is very likely not a transient issue. ▸ org.postgresql.util.PSQLException: ERROR: foreign key constraint "DeviceModel_network_nodeId_fkey" cannot be implemented ▸ Detail: Key columns "nodeId" and "id" are of incompatible types: character varying and uuid.

Going back to 1.26 works.

[nlko]

The problem is our implementation of scalar lists. Scalar lists are realized through a separate table that have foreign key to the table of the model itself. The foreign key is of type VARCHAR(25) but it tries to reference a column of type UUID. Therefore this error is thrown. With our current implementation we can't fix it. The solution is to implement native scalar lists that do not have this problem.

Hello everyone,

If I understand well this issue could be solved by correcting the type of the foreign key created by prisma ? (ie. long enough to store an UUID instead of just an ID)

If so, it sounds like a bug to me. Specially when there is this example in the doc:

type Article {
  tags: [String!]!
}

Maybe some explanation in the documentation stating that it is only possible when the id isn't longer than an ID should be enough.

I ended up switching from UUID to ID.

I didn't manage to make it work with 1.26 as previously stated.

By the way, I really enjoy working with prisma tools!

Have a good day,

Nicolas