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)
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
with regular update
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.
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.
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.
*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.
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.
Most helpful comment
All nested mutations inside
upsert
are now supported on the latest1.12-beta
version: https://github.com/prismagraphql/prisma/releases/tag/1.12.0-beta 馃檪