I have questions/concerns about the `@unique` attr...
# orm-help
n
I have questions/concerns about the
@unique
attribute (in my case, I'm using PostgreSQL). Basically, I understand how it works, but I think that the documentation/tutorials are in a way misleading, and could cause serious potential issues for a lot of users. The docs / tutorials frequently show examples were
@unique
is added to model fields as a constraint. This makes perfect sense for some most of Prisma's data types, but the thing that concerns me is when it is shown being used to enforce a unique constraint on
String
types, like emails and usernames. PostgreSQL uses deterministic collation by default, so filtering is case-sensitive by default. Yes, Prisma does offer case-insensitive filtering using
mode
, but I think a lot of people are going to set up their databases and not realize that, using just the
@unique
attribute, a user could sign up with
<mailto:ceo@corp.com|ceo@corp.com>
and another person could sign up with
<mailto:CeO@corp.com|CeO@corp.com>
, etc. I can't think of a single use case where you wouldn't want a string field for emails to be constrained in a case-sensitive way. Or a user could sign up with
jack
and another one could sign up with
jaCk
, etc. I understand that this is by design, and users can do things like enabling
citext
in PostgreSQL, or they could write client side logic to do a case-insensitive search for an existing user during sign up (This one in particular seems very brittle and not a very robust solution). The big issue to me is that the documentation doesn't seem to communicate that this very important implementational detail needs to be handled by the user themselves*. I'm not an expert with SQL or Prisma, so I'm fully aware I could be missing something, or I may have misunderstood how some of this works. Apologies in advance if that's the case. \: I'm fully aware that there are Prisma docs on case-sensitivity, case-insensitive filtering, and even ones that even mention
citext
, but I don't think they are easy to find, and they aren't referred to in many of the tutorials/examples/guides.*
If I should move this to a github issue / discussion let me know.
f
👋 @nonissue - thanks for the thorough message! The behavior of the constraint is defined by the database and not by Prisma (if DB column is case sensitive, so will be the unique constraint) so I feel this makes sense this way. What would you suggest as an improvement?
v
👋 hey @nonissue! Did you have a chance to see Frederik's comment? Let us know if you still have any questions or feedback!