feat(schema): add Project model and relation to User #8
Conversation
Add Project model with fields for title, type, and user relation. Include ProjectType enum to categorize projects.
WalkthroughAdds a new Project model and ProjectType enum to the Prisma schema, creates a one-to-many relation from Changes
Sequence Diagram(s)sequenceDiagram
autonumber
participant C as Client
participant API as API Server
participant P as Prisma
participant DB as Database
Note over C,DB #D3F9D8: Create Project flow (new)
C->>API: POST /projects { title, type, userId }
API->>P: prisma.project.create({ data: { title, type, user: { connect: { id: userId } } } })
P->>DB: INSERT INTO projects (...) VALUES (..., type::ProjectType, ...)
DB-->>P: Row inserted (FK userId validated)
P-->>API: Project record
API-->>C: 201 Created { project }
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Poem
Tip 👮 Agentic pre-merge checks are now available in preview!Pro plan users can now enable pre-merge checks in their settings to enforce checklists before merging PRs.
Example: reviews:
pre_merge_checks:
custom_checks:
- name: "Undocumented Breaking Changes"
mode: "warning"
instructions: |
Pass/fail criteria: All breaking changes to public APIs, CLI flags, environment variables, configuration keys, database schemas, or HTTP/GraphQL endpoints must be documented in the "Breaking Change" section of the PR description and in CHANGELOG.md. Exclude purely internal or private changes (e.g., code not exported from package entry points or explicitly marked as internal).Please share your feedback with us on this Discord post. Pre-merge checks (3 passed)✅ Passed checks (3 passed)
✨ Finishing Touches🧪 Generate unit tests
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (2)
prisma/schema.prisma (2)
36-41: Align enum casing with existing Role enum
Roleuses uppercase variants;ProjectTypeuses lowercase. Unify for consistency (new enum → safe to change now).-enum ProjectType { - post - article - ebook - script -} +enum ProjectType { + POST + ARTICLE + EBOOK + SCRIPT +}
45-46: Optional: constrain title and avoid duplicates per userIf titles are user-facing identifiers, consider a length bound and per-user uniqueness.
- title String + title String @db.VarChar(200)Add a composite unique (only if product requirements agree):
- @@map("projects") + @@unique([userId, title]) + @@map("projects")
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
prisma/schema.prisma(2 hunks)
🔇 Additional comments (1)
prisma/schema.prisma (1)
18-26: User ⇄ Project relation field looks correctThe one-to-many via
projects Project[]is correctly modeled and matchesProject.user/userId.
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (4)
prisma/migrations/20250909132930_added_projects/migration.sql (4)
9-10: Decide where “updatedAt” is enforced: DB vs. Prisma.Right now it’s NOT NULL without a DB default/trigger. Prisma’s @updatedat handles app writes, but raw SQL updates/inserts will violate expectations.
Option A (simple): set a default so inserts without Prisma don’t fail:
- "updatedAt" TIMESTAMP(3) NOT NULL, + "updatedAt" TIMESTAMP(3) NOT NULL DEFAULT CURRENT_TIMESTAMP,Option B (robust): DB trigger to auto-update on UPDATE:
CREATE OR REPLACE FUNCTION set_updated_at() RETURNS trigger AS $$ BEGIN NEW."updatedAt" = CURRENT_TIMESTAMP; RETURN NEW; END; $$ LANGUAGE plpgsql; CREATE TRIGGER projects_set_updated_at BEFORE UPDATE ON "public"."projects" FOR EACH ROW EXECUTE PROCEDURE set_updated_at();Also confirm this timestamp precision/type matches existing tables (TIMESTAMP vs TIMESTAMPTZ).
6-6: Consider a DB-side default for id (optional).You’re storing UUIDs as TEXT; Prisma’s @default(uuid()) will generate ids client-side. Add a DB default to support non-Prisma inserts.
- "id" TEXT NOT NULL, + "id" TEXT NOT NULL DEFAULT gen_random_uuid(),Note: requires pgcrypto. If unavailable, use uuid-ossp’s uuid_generate_v4(). Keep as TEXT to stay aligned with schema.prisma.
7-7: Guard title quality with a lightweight CHECK (and optional uniqueness).Prevents blank/whitespace-only titles and overly long values; optionally ensure per-user uniqueness.
"title" TEXT NOT NULL, + CONSTRAINT "projects_title_len_check" CHECK (char_length(btrim("title")) BETWEEN 1 AND 200),Optionally:
CREATE UNIQUE INDEX "projects_userId_title_uq" ON "public"."projects" ( "userId", lower(btrim("title")) );If you prefer model-driven control, mirror this as @@index/@@unique in schema.prisma.
17-17: Confirm delete semantics (RESTRICT vs CASCADE).RESTRICT preserves projects when a user is deleted; many domains prefer CASCADE for dependent rows.
If you want automatic cleanup:
-ALTER TABLE "public"."projects" ADD CONSTRAINT "projects_userId_fkey" FOREIGN KEY ("userId") REFERENCES "public"."users"("id") ON DELETE RESTRICT ON UPDATE CASCADE; +ALTER TABLE "public"."projects" ADD CONSTRAINT "projects_userId_fkey" FOREIGN KEY ("userId") REFERENCES "public"."users"("id") ON DELETE CASCADE ON UPDATE CASCADE;
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
prisma/migrations/20250909132930_added_projects/migration.sql(1 hunks)
🔇 Additional comments (2)
prisma/migrations/20250909132930_added_projects/migration.sql (2)
1-17: Solid, minimal migration.Enum + table + FK look consistent with the Prisma summary. No blockers from a DDL standpoint.
1-14: Types and timestamp conventions are consistent
userId is TEXT matching User.id, and createdAt/updatedAt use TIMESTAMP(3) consistently with existing migrations.
| "userId" TEXT NOT NULL, | ||
|
|
||
| CONSTRAINT "projects_pkey" PRIMARY KEY ("id") | ||
| ); | ||
|
|
||
| -- AddForeignKey | ||
| ALTER TABLE "public"."projects" ADD CONSTRAINT "projects_userId_fkey" FOREIGN KEY ("userId") REFERENCES "public"."users"("id") ON DELETE RESTRICT ON UPDATE CASCADE; |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Add an index on the foreign key for performance.
FK columns are common join/filter predicates; indexing avoids full scans and helps FK checks.
Apply after the table creation:
ALTER TABLE "public"."projects" ADD CONSTRAINT "projects_userId_fkey" FOREIGN KEY ("userId") REFERENCES "public"."users"("id") ON DELETE RESTRICT ON UPDATE CASCADE;
+
+-- Indexes
+CREATE INDEX "projects_userId_idx" ON "public"."projects" ("userId");If you frequently filter by user + type, consider a composite:
CREATE INDEX "projects_userId_type_idx" ON "public"."projects" ("userId","type");🤖 Prompt for AI Agents
In prisma/migrations/20250909132930_added_projects/migration.sql around lines 11
to 17, the migration adds a foreign key on "userId" but does not create an index
for that FK; add a CREATE INDEX statement after the ALTER TABLE to index
"userId" (e.g. name it projects_userId_idx) to speed joins and FK checks, and if
you commonly query by user and type create a composite index
projects_userId_type_idx on ("userId","type") instead; ensure the statements are
added after the table creation/ALTER so the migration applies the indexes.
Add Project model with fields for title, type, and user relation. Include ProjectType enum to categorize projects.
Summary by CodeRabbit