pantheon/hestia
2
0
Fork 0
Code Issues 23 Pull requests Projects Releases Packages Wiki Activity Actions

Create Residents table #78

Merged
BenjaminPalko merged 4 commits from 36-create-residents into master 2025-02-07 16:30:12 -05:00
Conversation 1 Commits 4 Files changed 7 +28 -1
3 changed files with 28 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files
Showing only changes of commit a9eb2ab65c - Show all commits

14
prisma/migrations/20250206142847_add_residents/migration.sql Normal file
View 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;
piopi commented 2025-02-06 13:50:05 -05:00 (Migrated from github.com)
Review
Copy link

Feel like it should be ON DELETE CASACADE but maybe it is prisma generating this

Feel like it should be ON DELETE CASACADE but maybe it is prisma generating this
BenjaminPalko commented 2025-02-06 22:04:53 -05:00 (Migrated from github.com)
Review
Copy link

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
piopi commented 2025-02-07 16:46:34 -05:00 (Migrated from github.com)
Review
Copy link

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.

2
prisma/migrations/migration_lock.toml
View file

@ -1,3 +1,3 @@
# Please do not edit this file manually # 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" provider = "postgresql"

13
prisma/schema.prisma
View file

@ -31,11 +31,24 @@ model User {
@@unique([clerkId, tenantId]) @@unique([clerkId, tenantId])
} }
model Resident {
id String @id @default(uuid())
DanMihailescu commented 2025-02-07 10:11:32 -05:00 (Migrated from github.com)
Review
Copy link

It should be marked as unique to ensure no duplicate residents

It should be marked as unique to ensure no duplicate residents
BenjaminPalko commented 2025-02-07 15:43:56 -05:00 (Migrated from github.com)
Review
Copy link

@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
piopi commented 2025-02-04 08:51:39 -05:00 (Migrated from github.com)
Review
Copy link

Missing the tenantId

Missing the tenantId
BenjaminPalko commented 2025-02-05 15:42:56 -05:00 (Migrated from github.com)
Review
Copy link

Fix, thanks!

Fix, thanks!
}
model Tenant { model Tenant {
id String @id @default(uuid()) id String @id @default(uuid())
clerkOrganizationId String @unique clerkOrganizationId String @unique
users User[] users User[]
residents Resident[]
tenantConfig TenantConfig? tenantConfig TenantConfig?
name String name String