Update Persistent Tasks

Update Persistent Tasks PATCH semantics, Prisma update, and P2025 translation

Phase 11 - Persistent Task CRUD API Volume 03 - Database Engineering

Architecture milestone PATCH /tasks/:id

↓

Prisma update

↓

durable row changes

Phase 11 replaces process memory with durable PostgreSQL-backed application behavior.

PATCH /tasks/:id - partial durable change
PATCH is appropriate when the client changes only part of a Task. The update body in this phase is
intentionally small: title, description, status, and priority.

@Patch(":id")
update(
@Param("id") id: string,
@Body() body: UpdateTaskInput,
) {
return this.tasksService.update(id, body);
}

Prisma update async update(id: string, input: UpdateTaskInput) { try { return await this.prisma.task.update({ where: { id }, data: input, }); } catch (error) { this.rethrowMissingTask(error, id); } }

Prisma performs a targeted UPDATE for the row selected by the unique id. updatedAt changes automatically because the schema marks it with @updatedAt.

Why catch P2025? For the locked Prisma 7 client used by this course, an update or delete that depends on a missing record can raise PrismaClientKnownRequestError with code P2025. We translate that database-client error into 404 for the HTTP contract.

private rethrowMissingTask( error: unknown, id: string, ): never { if ( error instanceof Prisma.PrismaClientKnownRequestError && error.code === "P2025" ) { throw new NotFoundException( `Task ${id} was not found.`, ); }

throw error; }

PowerShell update

$patch = @{ status = "DONE" priority = "HIGH" } | ConvertTo-Json

Invoke-RestMethod ` -Method Patch ` -Uri "http://127.0.0.1:4000/tasks/$taskId" ` -ContentType "application/json" ` -Body $patch

Important limitation

TypeScript says status is TaskStatus, but raw JSON is still untrusted at runtime. Phase 12 will reject values such as NOT_A_REAL_STATUS before they reach Prisma.

Business state comes later Phase 11 permits direct status changes because the goal is database CRUD. Larger workflows may eventually require rules such as DONE -> CANCELED being forbidden, or completedAt being synchronized. Those are service/business-rule concerns, not reasons to overload this persistence lesson.