Hacker News new | ask | show | jobs
by reducesuffering 685 days ago
I'm using Prisma ORM over Drizzle (didn't exist when I started).

When I need to add new data to a table I have, I just put the "new_column Type" in my prisma.schema for table X. and run "npx prisma migrate dev." Then everywhere else in my code, I already have the updated type for my object X.new_column and can access it with the guardrails of not betraying what type it is.

I'd rather do that than ALTER TABLE to create and update my read queries, while making sure I don't make a mistake in the raw SQL.

1 comments

Guardrails seems to be a common argument. It feels heavy handed though to use an entire library/ecosystem to ensure you don't have typos, your tests should catch them anyhow.

And migrations are a separate feature that a number of ORMs have, you can have clean migrations with pure SQL using a tool like gomigrate.

I think the real utility is that the ORM is doing the marshalling for you.

I can't speak for ORM's like ActiveRecord or Django's, but Prisma doesn't feel heavy handed to me at all. I'm doing mostly reads right now so all it does is:

#1: Schema in 1 simple file. No create/alter table

#2: migrations integrated with that schema. Don't need to pick out a migration lib like gomigrate or make sure it works well other ORM niceties.

#3: Simplified queries in lang of choice. Again, I didn't need to update SELECT statements at all for a new column, which could be several places in a codebase.

So it doesn't feel heavy handed when I end up touching only a few lines of ORM-related code compared to thousands of UI or business logic. I'll look up some Prisma-specific syntax maybe once a week.