Sanjay
07/31/2019, 12:08 AMJames
07/31/2019, 5:53 AMtmoney
07/31/2019, 5:47 PMshane
07/31/2019, 10:01 PMconst foo = inputObjectType({
name: 'foo',
definition(t) {
t.string('bar', { list: true, nullable: true })
}
})
generated input is always:
input foo {
bar: [String!]
}
desired outcome would be:
input foo {
bar: [String]
}
Chad H
08/01/2019, 1:23 AMJose Garcia
08/01/2019, 7:15 AMKolja Es
08/01/2019, 12:10 PMRejectedExecutionException
as well as memory spike that temporarily takes down our server (probably due to moving pages from memory to swap). Rough datamodel:
type User {
decks: [Deck]
}
type Deck {
creator: User!
cards: [Card]
learningState: [LearningState]
}
type Card {
repetitions: [Repetition]
}
type Repetition {
...
}
type LearningState {
...
}
Now we are using Prisma Client and our resolvers are basically set up according to the [guide](https://www.prisma.io/tutorials/a-guide-to-common-resolver-patterns-ct08#scenario-implementing-relations-with-prisma-client):
export default {
Query: {
decks: async (_, __, ctx: IContext) => {
const userId = …;
return prisma.decks({ where: { creator: { userId } } });
},
},
Deck: {
cards(parent) {
return prisma.deck({ id: parent.id }).cards();
},
// Same for creator and some other fields
},
}
Let’s assume we have a user with a single deck containing just two cards. This is our query:
decks {
...
learningState { … }
cards {
...
repetitions { … }
}
}
This produces the following queries (some batched together, shown by enabling tracking of slow queries and setting threshold to 0
):
1. decks (scalars)
2. batch: [deck#1 cards, deck#1 learningState]
3. batch: [deck#1 cards, deck#1 learningState] (exact duplicate of 2.)
4. batch: [card#1 repetitions, card#2 repetitions]
5. batch: [card#1 repetitions, card#2 repetitions] (exact duplicate of 4.)
As can be seen, there are a couple of duplicates.
We would like to keep using Prisma Client while reducing the number of queries so that the task queue is not flooded and our server stays alive 🙂 I’ve tried to make use of fragments but the cards are still queried individually.
Is it possible to eliminate the queries for each individual card? Are we correct in the assumption that queries of this form (e.g. with 1000+ cards) could cause memory spikes and thus downtime? Anyone else facing these problems? Thanks! (Happy to post this somewhere else if helpful)
prisma-client-lib, docker image, CLI all at 1.34.3.
Update: Changed post to reflect current situation.Bradley
08/01/2019, 2:17 PMreportsTo
field to null/no relation where reportsTo
is a relation to another User. Prisma Admin shows a relation to a user, however I always get this contradictory response... Any ideas? Documentation is little to none on disconnectspllumh
08/01/2019, 2:26 PMprisma-client-lib
which is generated with 'grapql create` command ?pllumh
08/01/2019, 2:28 PMRichard Perkins
08/01/2019, 2:45 PMJo
08/01/2019, 10:28 PMPkmmte
08/01/2019, 10:47 PMOlaf
08/02/2019, 5:20 AMrein
08/02/2019, 8:55 AMIsaac Weber
08/02/2019, 1:07 PMcaptaindaylight
08/02/2019, 4:20 PMtype Referral {
referrer: User! @relation(name: "UserReferrals")
referee: User! @relation(name: "UserReferee")
}
When I try to get the referral by the referee with prisma client, I’m doing this:
const referral = await prisma.referral({ where: { referee: { id: user.id } } });
But gotten the error:
Variable '$where' expected value of type 'ReferralWhereUniqueInput!' but got: {\"where\":{\"referee\":{\"id\":\"cjyu929lr00c7086128xdf46n\"}}}. Reason: 'where' Field 'where' is not defined in the input type 'ReferralWhereUniqueInput'. (line 1, column 8):\nquery ($where: ReferralWhereUniqueInput!)
Olaf
08/02/2019, 11:41 PM<http://example.com/user/12345|example.com/user/12345>
, is this the case for Prisma, since it generates an “ID” in no specific sequence? Or would I need to make a slug-like column for each user? What is acceptable?impowski
08/03/2019, 2:09 AMnexus
?tmoney
08/03/2019, 7:11 AMtmoney
08/04/2019, 1:26 AMLuke
08/04/2019, 1:59 AMdonedgardo
08/04/2019, 2:17 AMLuke
08/04/2019, 2:42 AMnileio
08/04/2019, 3:20 AMnileio
08/04/2019, 3:21 AMnileio
08/04/2019, 3:22 AMRoss O'Brien
08/04/2019, 1:59 PMcreateEvent(title: String!, description: String, startDate: DateTime!, locations: [Locations]): Event!
Am I right in saying once I run the actual mutation:
async createEvent(parent, args, ctx, info) {
const { title, description, locations, startDate } = args;
const { userId } = ctx.request;
const newEvent = await ctx.db.mutation.createEvent(
{
data: {
title,
description,
locations: { create: [...locations] },
startDate,
leader: {
connect: {
id: userId,
},
},
},
},
info
);
return newEvent;
Then newEvent
will only contain the id
, description
, startDate
and Locations
array?
I want to return everything defined in my Event
datamodel as I will be using it in a subscription:
type Event {
id: ID! @Unique @id
leader: User! @relation(name: “UserEvents”)
title: String!
description: String
startDate: DateTime!
attendees: [User] @relation(name: “AttendingEvents”)
locations: [Location] @relation(name: “EventLocations”)
comments: [Comment]
updatedAt: DateTime! @updatedAt
createdAt: DateTime! @createdAt
}
What is the best practice for doing this?
Thanks
Rosssoren
08/04/2019, 2:12 PMsoren
08/04/2019, 2:13 PM