Relations & Migrations — Series 3

Preview — 3 of 10 questions

Modeling a follows relationship, where any User can follow any number of other Users, requires a self-relation. How does Prisma express a many-to-many self-relation?

javascript

model User {
  id         Int    @id @default(autoincrement())
  following  User[] @relation("UserFollows")
  followedBy User[] @relation("UserFollows")
}

AThis is invalid — a model can never have a relation to itself

BA single, unnamed relation field is sufficient; Prisma infers the two directions automatically

CTwo relation fields, both pointing at User and sharing the same relation name ("UserFollows" here), represent the two directions of the same many-to-many relationship — following for the users this user follows, followedBy for the users following this user — with the shared name telling Prisma these two fields describe opposite sides of one relation, not two unrelated ones

DSelf-relations are only supported for one-to-one and one-to-many, never many-to-many

A Post has an optional authorId. What's the difference between these two nested update operations?

javascript

prisma.post.update({ where: { id: 1 }, data: { author: { disconnect: true } } });
prisma.post.update({ where: { id: 1 }, data: { author: { delete: true } } });

AThey're equivalent; both simply set authorId to null on the post

BBoth operations require the relation to be many-to-many; neither works on a one-to-many relation like this one

Cdisconnect deletes the related row; delete only removes the relationship

Ddisconnect: true removes the relationship between this post and its author — setting authorId to null — while leaving the User row itself completely untouched, still in the database. delete: true goes further: it removes the relationship and actually deletes the related User row from the database entirely

What does npx prisma migrate dev --create-only do differently from a plain npx prisma migrate dev?

AIt's identical to a plain migrate dev; the flag has no effect

BIt only works the very first time a project's migrations folder is created

CIt creates the migration file but skips generating the Prisma Client afterward

DIt generates the migration SQL file based on the current schema diff without actually applying it to the database — giving the opportunity to manually review or hand-edit the generated SQL (adding a data backfill statement, for instance) before running a follow-up migrate dev (with no flag) to actually apply it

Answer all 10 questions (7 more), see explanations for every answer, and track your score.