nonissue
06/29/2022, 10:12 PM@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.*nonissue
06/29/2022, 10:15 PMFrederik
06/30/2022, 12:33 PMVladi Stevanovic