Ecker
03/16/2019, 9:04 AMnull
for 90% of users. — So I've usually stored this as a JSON column in MySQL, which did work great back then. But with Prisma, graphql and graphql-bindings I see that this JSON approach would lose a lot of the power of graphql, making me have to do lots of manual validation on this json object. So I'm wondering how to best deal with lots of these meta values in Prisma?
type User {
id: ID! @unique
email: String! @unique
password: String!
meta1: Json! # ← My traditional approach, any data, any structure)
meta2: UserMeta! # ← Thinking this might be better?
}
type UserMeta {
role: UserRole!
newsletter: Boolean
# …etc, lots of other fields
}
enum UserRole {
MEMBER,
SUPER
}
But I still kinda dislike that the UserMeta
might grow to 20+ columns, and most of those columns will be null
or the default value for most users.Myer Nore
03/16/2019, 11:51 AMHoYeon
03/16/2019, 3:35 PMRyan Slama
03/16/2019, 4:24 PMRyan Slama
03/16/2019, 4:24 PMjblevins
03/16/2019, 6:25 PMezeikel
03/16/2019, 6:53 PM// datamodel.prisma
enum Permission {
ADMIN
USER
PERMISSIONUPDATE
}
enum Gender {
MALE
FEMALE
NONBINARY
NOTSPECIFIED
}
type User {
id: ID! @id
name: String
username: String @unique
website: String
bio: String
email: String! @unique
phoneNumber: Int
gender: Gender!
following: [User!]! @relation(name: "Following", link: INLINE)
followers: [User!]! @relation(name: "Followers", link: INLINE)
password: String!
resetToken: String
resetTokenExpiry: String
posts: [Post!]! @relation(name: "Posts", link: INLINE)
permissions: [Permission!]!
createdAt: DateTime! @createdAt
updatedAt: DateTime! @updatedAt
}
type Post {
id: ID! @id
author: User! @relation(name: "Author", link: INLINE)
image: String
caption: String
location: Location
published: Boolean @default(value: false)
likes: [User!]! @relation(name: "Likes", link: INLINE)
comments: [Comment!]!
createdAt: DateTime! @createdAt
}
type Location @embedded {
latitude: Float!
longitude: Float!
}
type Comment @embedded {
text: String!
writtenBy: User!
createdAt: DateTime! @createdAt
}
ezeikel
03/16/2019, 6:57 PMprisma deploy
ERROR: There is a relation ambiguity during the migration. Please first name the old relation on your schema. The ambiguity is on a relation between Post and User. Please name relations or change the schema in steps.
Im not sure why? Also, If anyone can let me know what the name
property does for `@relation`as I cant find it explained in the docsRodrigo Vieira
03/16/2019, 10:17 PMcsamu
03/16/2019, 11:18 PMJayphen
03/17/2019, 10:17 AMsubPlaces
is self-referential. I would like to query places(depth: Int!)
so that I can build a tree structure.
type Place {
id: ID! @unique
name: String!
things: [Thing]! @relation(name: "ThingsInPlace", onDelete: CASCADE)
subPlaces: [Place]
}
Pankaja
03/17/2019, 10:48 AMPankaja
03/17/2019, 10:49 AMPankaja
03/17/2019, 10:51 AMbtotharye
03/17/2019, 1:46 PMquery Snakes{
snakes(
where: {
OR: [
{name_contains: "pie"}
{description_contains: "pie"}
]
AND: [
{owner: {id: "someuseridhere"}}
]
}
) { id name}
}
antonbramsen
03/17/2019, 8:42 PMmedelman
03/17/2019, 11:55 PMprisma deploy
wants to deploy to prisma cloud (despite contents of prisma.yml
) but every other command, including prisma reset
appears to be working fine?James
03/18/2019, 2:07 AMYohann
03/18/2019, 6:15 AMgo4cas
03/18/2019, 6:46 AMFailed to resolve FK constraint
errors. Any way around this?Steve Mason
03/18/2019, 1:26 PMid: ID! @id
. When I try deploying to Prisma Cloud, I get this error:
User
✖ The field `id` is reserved and has to have the format: id: ID! @unique or id: UUID! @unique.
If I change my datamodel to id: ID! @unique
, it deloys to the cloud, but my local prisma client/db no longer works.
I’m using mongodb locally, does this make a difference? Here’s my prisma.yml
endpoint: ${env:PRISMA_CLIENT_ENDPOINT}
datamodel: server/datamodel.prisma
databaseType: document
secret: ${env:PRISMA_SECRET}
generate:
- generator: typescript-client
output: ./generated/prisma-client/
hooks:
post-deploy:
- prisma generate
I could programmatically include a different root datamodel with just the id types based on an env var, but that’s kinda weak I’d rather not if I don’t have to.
# prisma.yml
...
datamodel:
- ${env.PRISMA_ROOT_DATAMODEL}
- server/datamodel.prisma
Any ideas?btotharye
03/18/2019, 4:41 PMJosé Gomes
03/18/2019, 5:23 PMraul
03/18/2019, 6:59 PMraul
03/18/2019, 7:00 PMZyon
03/18/2019, 7:27 PMZyon
03/18/2019, 7:27 PMezeikel
03/18/2019, 10:57 PMfollow
and following
fields in ONE Mutation after one User follows another rather than having to fire off a separate Mutation for each User to update the respective fields like how it is done here https://github.com/prisma/prisma/issues/1609#issuecomment-365266599
async follow(parent, { username }, ctx, info) {
const auth0Id = await parseUserAuth0Id(ctx)
await ctx.db.mutation.updateUser({
where: { auth0Id },
data: {
following: {
connect: [{ username }]
}
}
})
return await ctx.db.mutation.updateUser({
where: { username },
data: {
followers: {
connect: [{ auth0Id }]
}
}
}, info)
},
async unfollow(parent, { username }, ctx, info) {
const auth0Id = await parseUserAuth0Id(ctx)
await ctx.db.mutation.updateUser({
where: { auth0Id },
data: {
following: {
disconnect: [{ username }]
}
}
})
return await ctx.db.mutation.updateUser({
where: { username },
data: {
followers: {
disconnect: [{ auth0Id }]
}
}
}, info)
},
Alex A
03/19/2019, 12:02 AMAlex A
03/19/2019, 12:02 AM