Prisma1: Nested mutation inside upsert mutations are not applied

Created on 11 Jan 2018  路  29Comments  路  Source: prisma/prisma1

Current behavior
if i execute an upsert with a connect inside (running 1.0 beta4) i get the following error: "Unsupported scalar value in SlickExtensions: Some(ListMap(connect -> Some(ListMap(id -> Some(cjc99y7q4006e0181fulirnrj)))))"
If i run the upsert without the connect everything works fine.

Reproduction

type Customer{
id: ID! @unique
name: String!
tenant: Tenant! @relation:"TenantCustomers"
}

type Tenant{
id: ID! @unique
name: String!
customers: [Customer!]! @relation:"TenantCustomers"
}

mutation UpsertCustomer($id: ID!, $name: String!) {
upsertCustomer(where: {id: $id}, create: {name: $name, mandant:{connect:{id:"Your Tenant Value"}}}, update: {name: $name}) {
    id
    name
    mandant{id}
  }
}

Result Playground

{
  "data": null,
  "errors": [
    {
      "message": "Unsupported scalar value in SlickExtensions: ListMap(connect -> Some(ListMap(id -> Some(Your Value))))",
      "locations": [
        {
          "line": 2,
          "column": 3
        }
      ],
      "path": [
        "upsertCustomer"
      ]

Result Server Debug Log

[GraphQL error]: Message: Unsupported scalar value in SlickExtensions: ListMap(connect -> Some(ListMap(id -> Some(Your Value)))), Location: [object Object], Path: upsertCustomer
Response from http://localhost:60001/XXX/dev:
null
Error: Unsupported scalar value in SlickExtensions: ListMap(connect -> Some(ListMap(id -> Some(Your Value))))
    at Object.checkResultAndHandleErrors (C:\dev\xxx\server\node_modules\graphql-tools\src\stitching\errors.ts:84:7)
    at Object.<anonymous> (C:\dev\xxx\server\node_modules\graphql-tools\src\stitching\delegateToSchema.ts:97:14)
    at step (C:\dev\xxx\server\node_modules\graphql-tools\dist\stitching\delegateToSchema.js:40:23)
    at Object.next (C:\dev\xxx\server\node_modules\graphql-tools\dist\stitching\delegateToSchema.js:21:53)
    at fulfilled (C:\dev\xxx\server\node_modules\graphql-tools\dist\stitching\delegateToSchema.js:12:58)
    at <anonymous>
    at process._tickDomainCallback (internal/process/next_tick.js:228:7)


bu2-confirmed

Most helpful comment

All nested mutations inside upsert are now supported on the latest 1.12-beta version: https://github.com/prismagraphql/prisma/releases/tag/1.12.0-beta 馃檪

All 29 comments

Can confirm that problem is still there with version graphcool/1.0.0-beta4.1.1

Got same error.
[Bugsnag - local / testing] Error report: com.bugsnag.Report@226cd50d
{"@timestamp":"2018-01-21T01:50:16.249+00:00","@version":1,"message":"{\"key\":\"request/new\",\"requestId\":\"api:api:cjco4ligo005q0111wz7g0h7f\"}","logger_name":"com.prisma.api.server.ApiServer","thread_name":"single-server-akka.actor.default-dispatcher-38","level":"INFO","level_value":20000,"HOSTNAME":"424e6d2ad611"}
java.lang.IllegalArgumentException: Unsupported scalar value in SlickExtensions: ListMap(id -> Some(cjco2o7ww0012011133mi90wb))

I'm getting something similar but i don't get an error in the playground, it just doesn't update it at all

$ prisma -v
- prisma/1.0.8 (darwin-x64) node-v8.9.3

with upsert
screen shot 2018-01-24 at 4 42 02 pm

with regular update
screen shot 2018-01-24 at 4 42 11 pm

You i have same problem, with not creating, updating, connecting nested stuff in upsert:

mutation {
  upsertService(where:{
    id:"cjctblxia001c0118lt40frbd"
  }
  create:{
    title:"Novy"
    url: {
      create: {
        link: "test"
        type:BLOG
      }
    }
  }
  update:{
    title:"Update"
    autor:{
      connect:{
        id:"cjcivkjd000et0161qox2rp8s"
      }
    }
  }) {
    id
    title
    url {
      link
      type
    }
    autor {
      name
    }
  }
}

From prisma logs:

{"@timestamp":"2018-01-24T20:52:37.965+00:00","@version":1,"message":"{\"key\":\"request/new\",\"requestId\":\"api:api:cjctjq5l9002v0118jqlcpq5j\"}","logger_name":"com.prisma.api.server.ApiServer","thread_name":"single-server-akka.actor.default-dispatcher-18","level":"INFO","level_value":20000,"HOSTNAME":"7d9a37077cd6"}
[Metrics] Warning: Metric SystemShared.sqlQueryTimer not enough / too many custom tag values given at recording time to fill the defined tags WrappedArray(CustomTag(projectId,1000), CustomTag(queryName,1000)). Ignoring custom tags.
item: DataItem(cjctblxia001c0118lt40frbd,Map(subtitle -> None, updatedAt -> Some(2018-01-24 17:05:31.0), published -> Some(false), createdAt -> Some(2018-01-24 17:05:23.0), content -> None, detail -> None, contentRaw -> None, title -> Some(Update), core -> Some(false)),Some(Service))
[Metrics] Warning: Metric SystemShared.sqlQueryTimer not enough / too many custom tag values given at recording time to fill the defined tags WrappedArray(CustomTag(projectId,1000), CustomTag(queryName,1000)). Ignoring custom tags.
[Metrics] Warning: Metric SystemShared.sqlQueryTimer not enough / too many custom tag values given at recording time to fill the defined tags WrappedArray(CustomTag(projectId,1000), CustomTag(queryName,1000)). Ignoring custom tags.

Now there is no error like before with ListMap

a workaround for this for the moment (at least my case) is to manually search for the node to update, if it finds it, update it, if not, create it.

Same issue here also, nested creates in an upsert mutation are not working and return no error. Is this a bug or just something that is a WIP?
update
Edit:
It looks like the embedded upserts in the generated update* functions are working so I'm rolling with that for now. Only seeing an issue with the upsert functions. Easy enough to work around it for the time being with separate mutations for create and update.

Prisma is great. Good work to all involved!

@do4gr has been working on this part of the code base. Maybe he can shed some light :-)

I have the Same issue but with upserts in update* functions as well.

screen shot 2018-01-29 at 14 16 55

screen shot 2018-01-29 at 14 17 38

Here is a screenshot of my request. Most of the upsert data is in json as it's generated by my js app. As you can see Prisma does not return any kind of error on the upsert. It does not create or update Blocks and returns an empty array.

screen shot 2018-02-05 at 9 51 16 am

The same error for deleteMany mutation

mutation{
  deleteManyCells(where:{ sheet:{id:"cjbnm5axu1kdt01475y4ak9lz"}}){
    count
  }
}

From prisma-database

java.lang.IllegalArgumentException: Unsupported scalar value in SlickExtensions: ListMap(id -> Some(cjbnm5axu1kdt01475y4ak9lz))
at com.prisma.api.database.SlickExtensions$.escapeUnsafeParam(SlickExtensions.scala:93)
at com.prisma.api.database.QueryArguments$.$anonfun$generateFilterConditions$2(QueryArguments.scala:351)
at scala.collection.TraversableLike.$anonfun$map$1(TraversableLike.scala:234)
...

Prisma version

prisma -v
prisma/1.1.3 (darwin-x64) node-v8.9.4

For mutation

mutation{
  deleteManyCells(where: { OR:[
    {id_:"cjcrb4mtqbki20172j730t1se"},
    {id:"cjcrb4mv9c09o0112pavliu83"}
  ]}){
    count
  }
}

Error

java.lang.ClassCastException: scala.collection.immutable.ListMap$Node cannot be cast to scala.collection.Seq
at com.prisma.api.database.QueryArguments$.$anonfun$generateFilterConditions$5(QueryArguments.scala:262)
at scala.collection.TraversableLike.$anonfun$map$1(TraversableLike.scala:234)
...

But

mutation {
  deleteManyCells(where: {id_in: ["cjcrb4mtqbki20172j730t1se", "cjcrb4mv9c09o0112pavliu83"]}) {
    count
  }
}

execute without errors

Thanks @lueurxax, this looks to be related to the relational filter!

I looked into the issues mentioned here.
@lueurxax , I can reproduce your error. But it is not related to the upsert case, could you please open a separate bug report for your error?

Regarding the upsert, there is a bug where we at the moment do not execute any nested mutations within upsert. A mutation like this works at the moment:

mutation x{ 
  upsertUser(
    where: {id:"x"},
    update: {name:"y"},
    create: {name:"z"})
 {name}
}

But any nested mutations within the create or update branch are ignored. This is true for a top-level upsert and also if the upsert itself is nested. Any errors on upsert that are not specifically an ignored nested mutation would constitute separate bugs.

Unfortunately the missing nested mutations within upsert are not a trivial bug, so I cannot give an ETA for the fix at the moment.

@lueurxax Your issue should be fixed with this PR https://github.com/graphcool/prisma/pull/1879 And will probably roll out tomorrow. So there is no need for a separate bug report anymore. Thanks for reporting the bug!

I'm still able to replicate this issue.

const identifier = context.db.mutation.upsertIdentifier({
        where: { hash },
        create: {
            hash,
            phoneNumber: { connect: { id: node.id } },
            verificationCodes: {
                create: [
                    {
                        code: VerificationCode.generateCode(),
                        validUntil: VerificationCode.generateValidUntil(),
                    },
                ],
            },
        },
        update: {
            hash,
            phoneNumber: { connect: { id: node.id } },
            verificationCodes: {
                create: [
                    {
                        code: VerificationCode.generateCode(),
                        validUntil: VerificationCode.generateValidUntil(),
                    },
                ],
            },
        },
    })

prisma/1.5.1 (darwin-x64) node-v9.8.0

Successfully creates the parent node, but nested mutations aren't applied. Really appreciate it if this issue could be resolved.

You can't connect nodes inside upsert yet, you can see it few messages up

Does anyone else not think that if this functionality is there listed in the Prisma API that it should _actually do_ what it says it does "on the tin"? Otherwise it should (temporarily) be removed from the generated API, or at the very least documented in the Prisma documentation here: https://www.prisma.io/docs/reference/prisma-api/mutations-ol0yuoz6go#upserting-nodes

You are completely right, @Siyfion! We are currently investigating if actually implementing the nested operations fits in our short-term roadmap. Depending on this decision, we will consider to remove the mutations from the API or not. Thanks for bringing this up!

Was this issue resolved with 1.10.0? The change log appears to describe a new feature that resolves this issue, but the linked issue seems unrelated.

Implemented the execution of connect, disconnect and delete when nested in the create or update branches of an upsert mutation #2565

No it wasn鈥檛.

All nested mutations inside upsert are now supported on the latest 1.12-beta version: https://github.com/prismagraphql/prisma/releases/tag/1.12.0-beta 馃檪

Hi
I am running 1.12.2 and doing a upsert with a nested create doesnt seem to create the nested item. Added this comment here as this is still open.

image

*response query fields edited after running

This is expected to work on 1.12.x.

Can you provide a reproduction, @dmce? That is, a datamodel + sequence of mutations that showcase the unexpected behaviour.

I am getting an internal server error with a connect inside an update inside of an upsert. Something like:

 upsert: {
      create: {
        persons: {
          create: [
            {
              name: "bob",
            },
          ],
          connect: [{ id: "cjkcug77n041c091103snc7yx" }],
        },
      },
     update: {
        persons: {
          create: [
            {
              name: "bob",
            },
          ],
     connect: [{ id: "cjkcug77n041c091103snc7yx" }],
        },
      },
    }
  }

Tried with 1.12 and 1.14-beta-1.

Error on server logs is: Duplicate entry 'cjkcvd9ek04730911qyfujpdg-cjkcug77n041c091103snc7yx' for key 'AB_unique'

The id cjkcug77n041c091103snc7yx is already connected. But I don't think it should error as we are doing an update/upsert here.

Thanks @develomark - this should have been fixed on 1.13.5 just now.

With this, I'm closing this issue.

It's solved! Thanks!

@marktani fantastic. Thank you for the speedy fix.

@marktani Is there a reason this won't work? On first call upsert is called and a new stats relation is created and connected, but the nested passing relation isn't. This causes a second call of upsert to fail because it cannot update the missing relation. Thoughts on what im doing wrong?

      await ctx.db.mutation.updatePlayer({
        where: { id: playerToUpdate[0].id },
        data: {
          stats: {
            upsert: {
              create: {
                gamesPlayed: stats.gamesPlayed,
                passing: {
                  create: {
                    passAttempts: stats.passing.passAttempts,
                    passCompletions: stats.passing.passCompletions,
                    passPct: stats.passing.passPct,
                  },
                },
              },
              update: {
                gamesPlayed: stats.gamesPlayed,
                passing: {
                  update: {
                    passAttempts: stats.passing.passAttempts,
                    passCompletions: stats.passing.passCompletions,
                    passPct: stats.passing.passPct,
                  },
                },
              },
            },
          },
        },
      });
type Player {
  id: ID! @unique
  ...
  stats: Stats
}

type Stats {
  id: ID! @unique
  gamesPlayed: Int
  passing: StatsPassing
}

type StatsPassing {
  id: ID! @unique
  passAttempts: Int
  passCompletions: Int
  passPct: Float
}



md5-f96492b9ebb5f15d05f6210c29e8148b



4:56:59 PM web.1 |  [Network error]: Error: The relation StatsToStatsPassing has no node for the model Stats connected to a Node for the model StatsPassing on your mutation path.
4:56:59 PM web.1 |  Error: The relation StatsToStatsPassing has no node for the model Stats connected to a Node for the model StatsPassing on your mutation path.

@danielmahon I don't see a reason for this failing. Would you mind creating a new issue report for this, so I can take a closer look? Please use the bug template: https://github.com/prismagraphql/prisma/issues/new?template=bug_report.md.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

schickling picture schickling  路  3Comments

schickling picture schickling  路  3Comments

marktani picture marktani  路  3Comments

marktani picture marktani  路  3Comments

akoenig picture akoenig  路  3Comments