Prisma.upsert() should support the value of null in where condition.

Bug description

Prisma supports creating the nullable value for the table, but not support the null value in where condition of upsert() method.

How to reproduce

I wrote a simple reproducible example - https://github.com/xuqingkuang/prisma-null-foreignkey

Please follow the README.

Expected behavior

upsert() accepts a null input as an option value.

Environment & setup

• OS: CentOS 8
• Database: MySQL and Sqlite
• Node.js version: v14.15.4
• Prisma version:

❯ npx prisma -v
Environment variables loaded from .env
prisma               : 2.20.1
@prisma/client       : 2.20.1
Current platform     : rhel-openssl-1.1.x
Query Engine         : query-engine 60ba6551f29b17d7d6ce479e5733c70d9c00860e (at node_modules/@prisma/engines/query-engine-rhel-openssl-1.1.x)
Migration Engine     : migration-engine-cli 60ba6551f29b17d7d6ce479e5733c70d9c00860e (at node_modules/@prisma/engines/migration-engine-rhel-openssl-1.1.x)
Introspection Engine : introspection-core 60ba6551f29b17d7d6ce479e5733c70d9c00860e (at node_modules/@prisma/engines/introspection-engine-rhel-openssl-1.1.x)
Format Binary        : prisma-fmt 60ba6551f29b17d7d6ce479e5733c70d9c00860e (at node_modules/@prisma/engines/prisma-fmt-rhel-openssl-1.1.x)
Default Engines Hash : 60ba6551f29b17d7d6ce479e5733c70d9c00860e
Studio               : 0.365.0

[garrensmith]

I’m closing this ticket. This is by design. Supporting null in a where clause removes the unique guarantee we have here.

[dpetrick]

That is entirely by design. Prisma has 2 core query concepts: Operate on a list of records or operate on a single record. Upsert falls into the single record category with the semantics being: “Find a single record and if that record exists, update it with the provided data, else create it with the provided data”. We categorize it strictly like that because a narrow definition allows us to implement queries without considering a larger class of edge cases that introduce uncertain behavior into Prisma.

So, to implement upsert we need to pin exactly one record in the database. IDs and uniques are the to do that in Prisma, any other (non-unique) condition would potentially result in a list of records and it is not clear which record to update (or update all, which breaks the semantics of the operation). Sidenote: “The first one” is also not acceptable because without an explicit ordering, there’s no guarantee that the first one is always the first one, among other edge cases.

Now the question is why we allow @@unique on nullable fields - that’s an SQL tradeoff we made so far. Your unique index in SQL is (in most cases) not really “unique” as we’d intuitively understand it, because you can totally have two identical titles with NULL as the authorId in the row (because in SQL, NULL != NULL, that’s why). However, the construct is so common that we had to include it, but as the interface requires you to find exactly one, we must require the input field and can’t accept null values, which is why there’s a deviation.

We may consider loosening restrictions in the future, but we will only do so after careful consideration when we are absolutely sure we understand all the use cases and problems it introduces.