Create Residents table #78
14
prisma/migrations/20250206142847_add_residents/migration.sql
Normal file
|
|
@ -0,0 +1,14 @@
|
|||
-- CreateTable
|
||||
CREATE TABLE "Resident" (
|
||||
"id" TEXT NOT NULL,
|
||||
"tenantId" TEXT NOT NULL,
|
||||
"name" TEXT NOT NULL,
|
||||
"phoneNumber" TEXT NOT NULL,
|
||||
"createdAt" TIMESTAMP(3) NOT NULL DEFAULT CURRENT_TIMESTAMP,
|
||||
"updatedAt" TIMESTAMP(3) NOT NULL,
|
||||
|
||||
CONSTRAINT "Resident_pkey" PRIMARY KEY ("id")
|
||||
);
|
||||
|
||||
-- AddForeignKey
|
||||
ALTER TABLE "Resident" ADD CONSTRAINT "Resident_tenantId_fkey" FOREIGN KEY ("tenantId") REFERENCES "Tenant"("id") ON DELETE RESTRICT ON UPDATE CASCADE;
|
||||
|
Cascade needs to be explicitly specified, I could see the desire to add that, but I can also see how it might be dangerous. If a tenant is accidentally deleted then it would cascade to all related tables and nuke a tenant completely, whereas with RESTRICT it would prevent this. Child tables would need to be removed FIRST before the parent, this would be a more explicit operation that would be less likely to be run on accident. Thanks for coming to my Ted talk Cascade needs to be explicitly specified, I could see the desire to add that, but I can also see how it might be dangerous. If a tenant is accidentally deleted then it would cascade to all related tables and nuke a tenant completely, whereas with RESTRICT it would prevent this. Child tables would need to be removed FIRST before the parent, this would be a more explicit operation that would be less likely to be run on accident.
Thanks for coming to my Ted talk
If a tenant is deleted it means they want their data out of the platform. Not making it cascade delete just makes it harder to fully delete a tenant data. ( You could protect the data with an appropriate backup policy and db roles) Cascade delete helps a lot when you setup your integration test and you delete your test tenant after each test, it makes the clean up of the test much easier. If a tenant is deleted it means they want their data out of the platform. Not making it cascade delete just makes it harder to fully delete a tenant data. ( You could protect the data with an appropriate backup policy and db roles)
Cascade delete helps a lot when you setup your integration test and you delete your test tenant after each test, it makes the clean up of the test much easier.
|
||||
|
|
@ -1,3 +1,3 @@
|
|||
# Please do not edit this file manually
|
||||
# It should be added in your version-control system (i.e. Git)
|
||||
# It should be added in your version-control system (e.g., Git)
|
||||
provider = "postgresql"
|
||||
|
|
@ -31,11 +31,24 @@ model User {
|
|||
@@unique([clerkId, tenantId])
|
||||
}
|
||||
|
||||
model Resident {
|
||||
id String @id @default(uuid())
|
||||
|
It should be marked as unique to ensure no duplicate residents It should be marked as unique to ensure no duplicate residents
@id is unique @id is unique
|
||||
tenant Tenant @relation(fields: [tenantId], references: [id])
|
||||
tenantId String
|
||||
|
||||
name String
|
||||
phoneNumber String
|
||||
|
||||
createdAt DateTime @default(now())
|
||||
updatedAt DateTime @updatedAt
|
||||
|
Missing the tenantId Missing the tenantId
Fix, thanks! Fix, thanks!
|
||||
}
|
||||
|
||||
model Tenant {
|
||||
id String @id @default(uuid())
|
||||
clerkOrganizationId String @unique
|
||||
|
||||
users User[]
|
||||
residents Resident[]
|
||||
tenantConfig TenantConfig?
|
||||
|
||||
name String
|
||||
|
|
|
|||
Feel like it should be ON DELETE CASACADE but maybe it is prisma generating this