I'm sure you could get even greater speed by removing Prisma. All you need is a migration tool and a database connection. Most recent example in my work where we removed an ORM resulted in all of our engineers, particularly juniors becoming Postgres wizards.

▲ PaulRobinson 4 hours ago | parent | next [-]

Congratulations, you have now increased the cognitive load to be productive on your team and increased the SQL injection attack surface for your apps!

I jest, but ORMs exist for a reason. And if I were a new senior or principal on your team I’d be worried that there was now an expectation for a junior to be a wizard at anything, even more so that thing being a rich and complex RDBMS toolchain that has more potential guns pointing at feet than anything else in the stack.

I spent many years cutting Rails apps and while ActiveRecord was rarely my favourite part of those apps, it gave us so much batteries included functionality, we just realised it was best to embrace it. If AR was slow or we had to jump through hoops, that suggested the data model was wrong, not that we should dump AR - we’d go apply some DDD and CQRS style thinking and consider a view model and how to populate it asynchronously.

▲

jakewins 3 hours ago | parent | next [-]

I think this needs some nuance - this is definitely true in some domains.

Most of the domains I worked in it was the other way around: using an ORM didn’t mean we could skip learning SQL, it added an additional thing to learn and consider.

In the last years writing SQLAlchemy or Django ORM the teams I was on would write queries in SQL and then spend the rest of the day trying to make the ORM reproduce it. At some point it became clear how silly that was and we stopped using the ORMs.

Maybe it’s got to do with aggregate-heavy domains (I particularly remember windowing aggregates being a pain in SQLAlchemy?), or large datasets (again memory: a 50-terabyte Postgres machine, the db would go down if an ORM generated anything that scanned the heap of the big data tables), or highly concurrent workloads where careful use of select for update was used.

	▲	tasuki an hour ago \| parent [-]
		> In the last years writing SQLAlchemy or Django ORM the teams I was on would write queries in SQL and then spend the rest of the day trying to make the ORM reproduce it. Ah yes, good times! Not Django for me but similar general idea. I'm not a big fan of ORMs: give me a type safe query and I'm happy!

▲

pjmlp 3 hours ago | parent | prev | next [-]

SQL injection is only a thing for those careless to ever allow doing screen concatenation to go through pull requests.

If it isn't using query parameters, straight rejection, no yes and buts.

Naturally if proper code review isn't a thing, than anything goes, and using an ORM won't help much either.

▲

9rx 3 hours ago | parent | prev [-]

Brainfuck also exists for a reason. That doesn't imply that you should use it.

▲ pjmlp 3 hours ago | parent | prev | next [-]

Same here, I am a big advocate of knowing your SQL, and stored procedures, no need to waste network traffic for what is never going to be shown on the application.

▲ AnotherGoodName 4 hours ago | parent | prev [-]

Using an ORM and escape hatching to raw SQL is pretty much industry standard practice these days and definitely better than no ORM imho. I have code that's basically a lot of

    result = orm.query({raw sql}, parameters)

It's as optimal as any other raw SQL query. Now that may make some people scream "why use an ORM at all then!!!" but in the meantime;

I have wonderful and trivially configurable db connection state management

I have the ability to do things really simply when i want to; i still can use the ORM magic for quick prototyping or when i know the query is actually trivial object fetching.

The result passing into an object that matches the result of the query is definitely nicer with a good ORM library than every raw SQL library i've used.

▲

RedShift1 3 hours ago | parent [-]

Every project I've come across that uses an ORM has terrible database design. All columns nullable, missing foreign key indexes, doing things in application code that could easily be done by triggers (fields like created, modified, ...), wrong datatypes (varchar(n) all over the place, just wwwhhhhyyy, floats for money, ...), using sentinel values (this one time, at bandcamp, I came across a datetime field that used a sentinel value and it only worked because of two datetime handling bugs (so two wrongs did make a right) and the server being in the UTC timezone), and the list goes on and on...

I think this happens because ORMs make you treat the database as a dumb datastore and hence the poor schema.

	▲	AnotherGoodName 3 hours ago \| parent [-]
		Honestly database schema management doesn't scale particularly well under any framework and i've seen those issues start to crop up in every org once you have enough devs constantly changing the schema. It happens with ORMs and with raw SQL. When that happens you really really should look into the much maligned no-sql alternatives. Similarly to the hatred ORMs get, no-sql data stores actually have some huge benefits. Especially at the point where db schema maintenance starts to break down. Ie. Who cares if someone adds a new field to the FB Newsfeed object in development when ultimately it's a key-value store fetched with graphQL queries? The only person it'll affect is the developer who added that field, no one else will even notice the new key value object unless they fetch it. There's no way to make SQL work at all at scale (scale in terms of number of devs messing with the schema) but a key-value store with graphQL works really well there. Small orgs where you're the senior eng and can keep the schema in check on review? Use an ORM to a traditional db, escape hatch to raw SQL when needed, keep a close eye on any schema changes. Big orgs where there's a tons of teams wanting to change things at high velocity? I have no idea how to make either SQL or ORMs work in these cases. I do know from experience how to make graphQL and a key-value store work well though and that's where the above issues happen in my experience. It's really not an ORM specific issue. I suggest going down the no-sql route in those cases.