Prisma1: Choosing UUID for the id field breaks create mutations

[marktani]

Describe the bug
If you set your id field to be of type UUID, the create mutation won't work.

To Reproduce

1. Add a new type like this to your datamodel:

type Test {
  id: UUID! @unique
  test: String!
}

1. Deploy
2. Run this mutation:

mutation {
  createTest(data: {test: "abc"}) {
    id
  }
}

1. You'll receive an internal server error:

java.sql.SQLException: (conn=820223) Incorrect string value: '\xAC\xED\x00\x05sr...' for column 'id' at row 1

Expected behavior

• Either, we cannot set UUID for the id field
• Or, when running createTest as above, the id field is automatically generated.

Versions (please complete the following information):

• Prisma Server: 1.18-beta-1

Additional context
Current workaround: use id: ID! @unique instead.

[mavilein]

This only happens for the MySQL connector. For Postgres it just works.

[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.

[kshenes]

Is there a plan to get this resolved? It makes UUIDs hard to use with MySQL.

prisma 1.23.0

java.lang.Thread.run(Thread.java:748)","message":"(conn=5) Incorrect string value: '\xAC\xED\x00\x05sr...' for column 'id' at row 1"}}
[Bugsnag - local / testing] Error report: com.bugsnag.Report@76edad95
java.sql.SQLException: (conn=5) Incorrect string value: 'xACxEDx00x05sr...' for column 'id' at row 1
on fixing this

[mavilein]

@kshenes : Why do you want to use UUIDs instead of our normal IDs? My original plan was to not allow UUIDs for the MySQL connector going forward.

[kshenes]

We have a customer requirement to have every object instance be identified by a UUID so it can be reconciled to its origin when encountered in logs. They are unable to change their existing harvesting system to use the ID format. Also just to add a data point. In my 20+ years working with distributed system I would say 90% of them relied on UUID/CUID/GUID at some level. Some of them generate the UUID based on the natural keys of the object, so supporting @autogenerate vs @required would also be a bonus.

[kshenes]

@mavilein Since prisma is advertising as an ORM, do you think it wise to introduce such inconsistencies between database connectors? What if I standup Postgres as my DBMS and find I need to switch to a different one and the basic supported types are different.

[mavilein]

@kshenes : I agree that not having this inconsistency is better. However we are using JDBC to interact with MySQL and Postgres. But those drivers do not behave consistenly with respect to UUIDs unfortunately. We definitely want to lift this constraint in the future and i am asking those questions just to get a better understanding. So in your case it is rather a matter of integrating with an existing system. Thanks that helps 🙏 👍

[kshenes]

OK, we can add secondary uuid fields, quick questions, 1) any time frame on roachDB? 2) secondary/alternate index creation?

[mavilein]

@kshenes :

1. What's roachDB?
2. We have a PR for this in the works. We will pick it up at the beginning of the new year again.

[kshenes]

sorry for the Brevity. I was speaking about Cockroachdb https://www.cockroachlabs.com/product/cockroachdb/

I thought I heard there was a movement about creating an adapter for it?

[shakahl]

We have faced with this problem too. UUID support for MySQL would be nice since our system relies on UUIDs too.

[pantharshit00]

Datamodel 1.1 allows custom IDs so we can provide a custom UUID there for MySQL

https://github.com/prisma/datamodel-v1.1-feedback

[divyenduz]

We do not allow UUID with MySQL on id fields anymore.

We do have a separate bug that allows you to deploy UUID to non id fields on MySQL, that is being tracked here: https://github.com/prisma/prisma/issues/4344

I am closing this one, please feel free to open a new issue in case you feel strongly about it.