After running into an issue trying things out on my own, I tried the example from the docs and I ran into a similar issue, is the doc wrong, or am I doing something stupid?
The example I am trying to execute is the one from this page: https://www.apollographql.com/docs/apollo-server/federation/introduction/
The relevant piece of code is:
const server = new ApolloServer({
schema: buildFederatedSchema([{
typeDefs: gql`
extend type Query {
me: User
}
type User #key(fields: "id") {
id: ID!
username: String!
}
`,
resolvers: [],
}, {
typeDefs: gql`
extend type Query {
topProducts(first: Int = 5): [Product]
}
type Product #key(fields: "upc") {
upc: String!
name: String!
price: Int
}
`,
resolvers: [],
}, {
typeDefs: gql`
type Review {
body: String
author: User #provides(fields: "username")
product: Product
}
extend type User #key(fields: "id") {
id: ID! #external
reviews: [Review]
}
extend type Product #key(fields: "upc") {
upc: String! #external
reviews: [Review]
}
`,
resolvers: [],
}]),
context: ({ req }) => ({ user: req.user }),
})
Note that I left the resolvers empty on purpose, I am just trying to compile the schema.
Here is the error I get:
GraphQLSchemaValidationError: Field "User.id" can only be defined once. Field "Product.upc" can only be defined once.
Can someone help me out with that?
Related
Schema:
type Mutation {
removeProduct(id: String!): Product
}
type Product {
id: ID!
name: String!
slug: String!
description: String!
price: Float!
image: String!
ingredients: [String]
addOns: [String]
}
resolver:
exports.Mutation = {
removeProduct: async (parent, { id }, { Product }) => {
const deletedProduct = await Product.deleteOne({ id });
return deletedProduct;
},
};
query:
mutation{
removeProduct(id:"b55572b9-eb4d-46ea-a82f-f01cb0ba3993")
{
id
name
}
}
I need to remove a product from the db, but while deleting it, the response from graphql shows that "message": "Cannot return null for non-nullable field Product.name.",
It maybe because the product is deleted and nothing is returned because there is no product in db.
How do I write a query to delete a product ?
Note that it deletes the product from the db, but shows error in graphql response.
Within my resolver I seem to be unable to fetch connected data
this works in the graphql playground (prisma) but I am unsure of the syntax about how to form a resolver in apollo server
// my typedef for activity is
type Activity {
id: ID! #id
ActivityType: ActivityType!
title: String!
date: DateTime
user: User!
distance: Float!
distance_unit: Unit!
duration: Float!
elevation: Float
elevation_unit: Unit
createdAt: DateTime! #createdAt
updatedAt: DateTime! #updatedAt
// and my resolver currently looks like this
async activity(parent, args, ctx, info) {
const foundActivity = await ctx.db.query.activity({
where: {
id: args.id
}
});
// todo fetch user data from query
console.log(foundActivity);
}
// where db has been placed onto the ctx (context)
// the CL gives all of the data for Activity apart from the user
// in the playground I would do something like this
query activity {
activity(where: {
id: "cjxxow7c8si4o0b5314f9ibek"
}){
title
user {
id
name
}
}
}
// but I do not know how to specify what is returned in my resolver.
console.log(foundActivity) gives:
{ id: 'cjxxpuh1bsq750b53psd2c77d',
ActivityType: 'CYCLING',
title: 'Test Activity',
date: '2019-07-10T20:21:27.681Z',
distance: 13.4,
distance_unit: 'KM',
duration: 90030,
elevation: 930,
elevation_unit: 'METERS',
createdAt: '2019-07-10T20:48:50.879Z',
updatedAt: '2019-07-10T20:48:50.879Z' }
Prisma is the DB ORM and then I have an Apollo-Server 2 server running on top of that. Unfortunately, stack overflow also thinks that there is too much code on this post so I will have to waffle on about inconsequential gibberish due to the fact that their system can't handle it.
You will have to implement a resolver for Activity.user. Unfortunately your entity does not seem to contain a reference to the user. First, add the user connection to your Prisma data model. Then implement a resolver for Activity.user. I am not very familiar with Prisma 1 but this naive implementation should already do what you want:
let resolvers = {
Query: {
// ...
},
Activity: {
user(parent, args, ctx) {
return ctx.db.query.activity({ id: parent.id }).user();
}
}
}
Find out more about resolving relations in Prisma here
So the answer was incredibly simple:
I just add a second argument to the query (after the "where" with a gql tag of the data shape to be returned so my code now looks like:
const foundActivity = await ctx.db.query.activity(
{
where: {
id: args.id
}
},
`{id title user { id name }}`
);
I'm trying to figure out cascade deletion in GraphQL.
I'm attempting to delete a node of type Question, but type QuestionVote has a required relation to Question. I'm looking for a way to delete a Question and all its votes at once.
Mutation for deleting a Question:
type Mutation {
deleteQuestion(where: QuestionWhereUniqueInput!): Question!
}
And its resolver (I'm using Prisma):
function deleteQuestion(parent, args, context, info) {
const userId = getUserId(context)
return context.db.mutation.deleteQuestion(
{
where: {id: args.id}
},
info,
)
}
How can I modify that mutation to also delete related QuestionVote nodes? Or should I add a separate mutation that deletes one or multiple instances of QuestionVote?
In case it's important, here are the mutations that create Question and QuestionVote:
function createQuestion(parent, args, context, info) {
const userId = getUserId(context)
return context.db.mutation.createQuestion(
{
data: {
content: args.content,
postedBy: { connect: { id: userId } },
},
},
info,
)
}
async function voteOnQuestion(parent, args, context, info) {
const userId = getUserId(context)
const questionExists = await context.db.exists.QuestionVote({
user: { id: userId },
question: { id: args.questionId },
})
if (questionExists) {
throw new Error(`Already voted for question: ${args.questionId}`)
}
return context.db.mutation.createQuestionVote(
{
data: {
user: { connect: { id: userId } },
question: { connect: { id: args.questionId } },
},
},
info,
)
}
Thanks!
You can set up cascade deletion by modifying your datamodel.
Given your question, I assume your datamodel looks somewhat like this:
type Question {
id: ID! #unique
votes: [QuestionVote!]! #relation(name: "QuestionVotes")
text: String!
}
type QuestionVote {
id: ID! #unique
question: Question #relation(name: "QuestionVotes")
isUpvote: Boolean!
}
Then you have to add the onCascade: DELETE field to the #relation directive like so:
type Question {
id: ID! #unique
votes: [QuestionVote!]! #relation(name: "QuestionVotes" onDelete: CASCADE)
text: String!
}
type QuestionVote {
id: ID! #unique
question: Question #relation(name: "QuestionVotes")
isUpvote: Boolean!
}
Now, every time a Question node is deleted, all related QuestionVote nodes are also deleted.
Note: If omitting onDelete, the value is automatically set to onDelete: SET_NULL by default. This means that deleting a node results in setting the other side of the relation to null.
You can read more about cascading deletes in Prisma in the documentation.
I am using Prisma with GraphQL and get errors when I run the mutatioin.
I deployed prisma succussfully and binded it with local graphQL.
-- datamodel.graphql - prisma setting
type Link {
id: ID! #unique
description: String!
url: String!
postedBy: User
}
type User {
id: ID! #unique
name: String!
email: String! #unique
password: String!
links: [Link!]!
}
-- schema.graphql - local setting
# import Link from "./generated/prisma.graphql"
type Query {
info: String!
feed: [Link!]!
}
type Mutation {
post(url: String!, description: String!): Link!
signup(email: String!, password: String!, name: String!): AuthPayload
login(email: String!, password: String!): AuthPayload
}
type AuthPayload {
token: String
user: User
}
type User {
id: ID!
name: String!
email: String!
links: [Link!]!
}
Resolver for signup mutation is
async function signup(parent, args, context, info) {
// 1
const password = await bcrypt.hash(args.password, 10)
// 2
const user = await context.db.mutation.createUser({
data: { ...args, password },
}, `{ id }`)
// 3
const token = jwt.sign({ userId: user.id }, APP_SECRET)
// 4
return {
token,
user,
}
}
And this is .graphqlconfig.yml content
projects:
app:
schemaPath: src/schema.graphql
extensions:
endpoints:
default: http://localhost:4000
database:
schemaPath: src/generated/prisma.graphql
extensions:
prisma: database/prisma.yml
GraphQL query I run is .
mutation {
signup(
name: "Alice"
email: "alice#graph.cool"
password: "graphql"
) {
token
user {
id
}
}
}
And the response I got when I run this is
{
"data": {
"signup": null
},
"errors": [
{
"message": "Variable '$_data' cannot be non input type 'UserCreateInput!'. (line 1, column 19):\nmutation ($_data: UserCreateInput!) {\n ^",
"locations": [],
"path": [
"createUser"
]
}
]
}
I can'find the reason of this.
Thank you.
Try use prisma deploy --force
This worked for me.
Fixed it by changing to the right endpoint in index.js
const server = new GraphQLServer({
typeDefs: './src/schema.graphql',
resolvers,
context: req => ({
...req,
db: new Prisma({
typeDefs: 'src/generated/prisma.graphql',
endpoint: 'http://localhost:4466/local/dev',
secret: 'secret',
debug: true,
}),
}),
})
I think your prisma.yml was wrong.
# The endpoint represents the HTTP endpoint for your Prisma API. It encodes
# several pieces of information:
# * Prisma server (`localhost:4466` in this example)
# * Service name (`myservice` in this example)
# * Stage (`dev` in this example)
# NOTE: When service name and stage are set to `default`, they can be omitted.
# Meaning http://myserver.com/default/default can be written as http://myserver.com.
endpoint: http://localhost:4466/myservice/dev
So, I'm testing subscriptions on Graphcool and would appreciate some clarification on how exactly they work.
I have a one to many relationship from Posts on Comments:
Schema
type Posts {
caption: String!
comments: [Comments!]! #relation(name: "PostsOnComments")
createdAt: DateTime!
displaysrc: String!
id: ID!
likes: Int
updatedAt: DateTime!
}
type Comments {
createdAt: DateTime!
id: ID!
posts: Posts #relation(name: "PostsOnComments")
text: String!
updatedAt: DateTime!
user: String!
}
The subscription I run in Graphcool is as follows:
subscription CreatedDeletedComments {
Comments(
filter: {
mutation_in: [CREATED, DELETED]
}
) {
mutation
node {
id
user
text
}
}
}
If I run the following in my React app, a created notification is fired:
return this.props.client.mutate({
mutation: gql`
mutation createComment ($id: ID, $textVal: String!, $userVal: String!) {
createComments (postsId: $id, text: $textVal, user: $userVal){
id
text
user
}
}
`,
variables: {
"id": postID,
"textVal": textVal,
"userVal": userVal
},
// forceFetch: true,
})
But if I run the following, no deleted notification is fired:
return this.props.client.mutate({
mutation: gql`
mutation removeComment ($id: ID!, $cid: ID!) {
removeFromPostsOnComments (postsPostsId: $id, commentsCommentsId: $cid){
postsPosts {
id
displaysrc
likes
comments {
id
text
user
}
}
}
}
`,
variables: {
"id": postID,
"cid": commentID
},
// forceFetch: true,
})
What am I overlooking here?
With the subscription
subscription CreatedDeletedComments {
Comments(
filter: {
mutation_in: [CREATED, DELETED]
}
) {
mutation
node {
id
user
text
}
}
}
you are subscribing to comment nodes being created or deleted. However, with the mutation removeFromPostsOnComments, you are not deleting any comment nodes. Instead, you are only deleting the connection between a post and a comment.
You can adjust your mutation request to delete the comment entirely instead of disconnecting it from the post:
return this.props.client.mutate({
mutation: gql`
mutation removeComment ($cid: ID!) {
deleteComment(id: $cid) {
id
}
}
`,
variables: {
"cid": commentID
},
// forceFetch: true,
})
If you don't want to delete the comment entirely but still want to hide it in your app, you could have a boolean field deleted that acts as a soft deletion marker.
Then you could subscribe to UPDATED comments instead of DELETED comments and check if the field deleted was updated. Refer to the
docs for more information on how to do that with updatedFields.
Subscriptions for relations is also already part of our roadmap.