Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create ExerciseComment database table #2404

Merged
merged 11 commits into from
Oct 19, 2022
Merged

Create ExerciseComment database table #2404

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
11 commits
Select commit Hold shift + click to select a range
d7d2f5e
create discussions table in prisma
HS-90 Oct 6, 2022
488fe1a
Merge branch 'master' into discussions-backend
flacial Oct 7, 2022
f5a3e8f
Merge branch 'master' into discussions-backend
flacial Oct 10, 2022
ebf3d8c
Merge branch 'garageScript:master' into discussions-backend
HS-90 Oct 13, 2022
9c43845
Merge branch 'garageScript:master' into discussions-backend
HS-90 Oct 14, 2022
b15b3c8
revision to Discussions table after team meeting
HS-90 Oct 14, 2022
fbb00cd
Merge branch 'master' into discussions-backend
HS-90 Oct 16, 2022
76e3554
change ExerciseComments to ExerciseComment
HS-90 Oct 16, 2022
0955ccc
Merge branch 'master' into discussions-backend
HS-90 Oct 17, 2022
e660fab
Merge branch 'master' into discussions-backend
HS-90 Oct 19, 2022
9bacfc3
Merge branch 'master' into discussions-backend
HS-90 Oct 19, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
22 changes: 22 additions & 0 deletions prisma/migrations/20221006161259_create_discussions_table/migration.sql
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,22 @@
-- CreateTable
CREATE TABLE "Discussion" (
"id" SERIAL NOT NULL,
"createdAt" TIMESTAMPTZ(6) NOT NULL DEFAULT CURRENT_TIMESTAMP,
"updatedAt" TIMESTAMPTZ(6) NOT NULL,
"authorId" INTEGER NOT NULL,
"exerciseId" INTEGER NOT NULL,
"userPic" TEXT NOT NULL,
"content" TEXT NOT NULL,
"parentId" INTEGER,

CONSTRAINT "Discussion_pkey" PRIMARY KEY ("id")
);

-- AddForeignKey
ALTER TABLE "Discussion" ADD CONSTRAINT "Discussion_authorId_fkey" FOREIGN KEY ("authorId") REFERENCES "users"("id") ON DELETE CASCADE ON UPDATE CASCADE;

-- AddForeignKey
ALTER TABLE "Discussion" ADD CONSTRAINT "Discussion_exerciseId_fkey" FOREIGN KEY ("exerciseId") REFERENCES "exercises"("id") ON DELETE CASCADE ON UPDATE CASCADE;

-- AddForeignKey
ALTER TABLE "Discussion" ADD CONSTRAINT "Discussion_parentId_fkey" FOREIGN KEY ("parentId") REFERENCES "Discussion"("id") ON DELETE SET NULL ON UPDATE CASCADE;
2 changes: 2 additions & 0 deletions prisma/migrations/20221006161545_create_discussions_table2/migration.sql
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,2 @@
-- AlterTable
ALTER TABLE "Discussion" ALTER COLUMN "userPic" DROP NOT NULL;
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Setting userPic to not null, since not every user may have uploaded a profile picture

5 changes: 5 additions & 0 deletions prisma/migrations/20221006163340_create_discussions_table3/migration.sql
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,5 @@
-- DropForeignKey
ALTER TABLE "Discussion" DROP CONSTRAINT "Discussion_authorId_fkey";

-- AddForeignKey
ALTER TABLE "Discussion" ADD CONSTRAINT "Discussion_authorId_fkey" FOREIGN KEY ("authorId") REFERENCES "users"("id") ON DELETE SET NULL ON UPDATE CASCADE;
flacial marked this conversation as resolved.
Show resolved Hide resolved
18 changes: 18 additions & 0 deletions prisma/schema.prisma
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -156,6 +156,7 @@ model User {
submissionsReviewed Submission[] @relation("userReviewedSubmissions")
submissions Submission[] @relation("userSubmissions")
userLessons UserLesson[]
discussions Discussion[]

@@map("users")
}
Expand Down Expand Up @@ -193,6 +194,7 @@ model Exercise {
flaggedBy User? @relation("flaggedExercises", fields: [flaggedById], references: [id])
module Module @relation(fields: [moduleId], references: [id], onDelete: Cascade)
submissions ExerciseSubmission[]
discussions Discussion[]

@@map("exercises")
}
Expand All @@ -207,3 +209,19 @@ model ExerciseSubmission {

@@map("exerciseSubmissions")
}

model Discussion {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm a little bit confused by naming this table Discussion. Wouldn't Comment make more sense?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel Discussion refer to the feature whilst a Comment refer to the comments in the Discussion.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

image

Open to suggestions about naming it something different but there's already a Comment table.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about DiscussionComment?

Copy link
Collaborator

@anthonykhoa anthonykhoa Oct 6, 2022 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Lets finalize all these details before implementation. After implementing this model, we should not have to be touching this model in the backend anymore to finish implementing a MVP for the discussions flow

Copy link
Member

@flacial flacial Oct 6, 2022 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Lets finalize all these details before implementation. After implementing this model, we should not have to be touching this model in the backend anymore to finish implementing a MVP for the discussions flow

What do you mean by "finalize"? And when is a design doc is considered complete?

Copy link
Collaborator

@anthonykhoa anthonykhoa Oct 7, 2022 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we are following a design doc, all of the architecture should be decided upon before implementation. By finalized details I mean complete design doc. What a complete design doc looks like will differ depending on what feature the design doc was made for. Here are good tips on design docs, it's also in our engineering practices
https://www.industrialempathy.com/posts/design-docs-at-google/

For this discussions flow design doc, enough should be outlined such that the backend and frontend can start work in parallel. If we are still deciding on how the backend should be setup, then that means the frontend can't be worked on yet since the frontend relies on how the backend is setup

id Int @id @default(autoincrement())
createdAt DateTime @default(now()) @db.Timestamptz(6)
updatedAt DateTime @updatedAt @db.Timestamptz(6)
authorId Int
exerciseId Int
userPic String?
flacial marked this conversation as resolved.
Show resolved Hide resolved
content String
parentId Int?
exercise Exercise @relation(fields: [exerciseId], references: [id], onDelete: Cascade)
author User @relation(fields: [authorId], references: [id], onDelete: SetNull)
parent Discussion? @relation("DiscussionReplies", fields: [parentId], references: [id])
replies Discussion[] @relation("DiscussionReplies")

}