Prisma1: `set` only overrides first n elements instead of replacing existing list entirely in `update`-mutation

[nikolasburk]

Bug Report

Current behavior

set only overrides first n elements instead of replacing existing list entirely in update-mutation

Reproduction

1. Create new project with the following data model

   type User {
    id: ID! @unique
    scores: [Int!]!
   }
   

2. Send mutation:

   mutation {
     createUser(data: {
       scores: {
         set: [1,2,3,4,5]
       }
     }) {
       id
     }
   }
   

3. Send mutation:

   mutation {
     updateUser(where: {
       id: "cjd4lfdyww0h00144zst9alur"
     }, data: {
       scores: {
         set: [10, 20]
       }
     }) {
       id
     }
   }
   

4. Send query:

   {
     users {
       scores
     }
   }
   

5. Scores has the following values:

    "scores": [
         10,
         20,
         3,
         4,
         5
       ]
   

Expected behavior?

1. Scores should have the following values:

    "scores": [
         10,
         20
       ]
   

[frankdugan3]

Additionally, when performing an update mutation via the JS Prisma API the field being updated is not returned, which throws Cannot return null for non-nullable field. Not sure if this is directly related or not.

[marktani]

That's very likely a usage problem @frankdugan3, please describe your situation in a new Forum thread 🙂

[frankdugan3]

@marktani I was about to edit my comment to be more specific, but this only occurs when updating the scalar lists with set as described in the OP. The same exact resolver works fine with all other fields types.

[marktani]

Can you reproduce this behaviour in the Playground directly?

[frankdugan3]

@marktani Ahh, I figured out my problem. I needed to pass info to the updateUser mutation, otherwise Prisma didn't know I needed the nested query. The official examples and templates I've seen usually omit info in resolvers. Is it only needed for nested fields, or should it just be included at all times? Perhaps some clarification in the docs would be helpful.

Still experiencing the OP's issue, though.

[marktani]

There are three general cases for the info parameter, they are all described here: https://www.graph.cool/forum/t/querying-specific-fields-in-db-from-local-service-with-prisma/2075/4?u=nilan

Would love to see a PR to translate that info into this tutorial 🙂

[frankdugan3]

I may take stab at that sometime this weekend. Thanks!

[do4gr]

The backend issue should be fixed by https://github.com/graphcool/prisma/pull/1807.

[marktani]

This has now been released in 1.1.3 🎉