I don't like ORMs, but Prisma is one of the better ones. It avoids a lot of shortcomings of popular ORMs. I hope they find a way to make it work as a company. I've been following them over the years from the beginning of their journey through various pivots. To use an ORM effectively you must learn both the API of the ORM and SQL. It does not absolve you from learning SQL, which I think was one of the unstated attrac…
Prisma – ORM for Node.js and TypeScript
221–230 of 260 posts
Re: Prisma – ORM for Node.js and TypeScript
#222I don't like ORMs, but Prisma is one of the better ones. It avoids a lot of shortcomings of popular ORMs. I hope they find a way to make it work as a company. I've been following them over the years from the beginning of their journey through various pivots. To use an ORM effectively you must learn both the API of the ORM and SQL. It does not absolve you from learning SQL, which I think was one of the unstated attrac…
I despise ORMs. I don't judge programmers very often, but invariably if there is an ORM, there is a fragile, tightly coupled, difficult-to-maintain project nearby
Re: Prisma – ORM for Node.js and TypeScript
#223Re: Prisma – ORM for Node.js and TypeScript
#224Earlier quoted context omitted.
The great thing about SQL is the relational model. You typically can't compose parts of SQL queries easily from the programming language calling it, but SQL queries themselves compose incredibly flexibly. The result of of a SELECT query is itself a "relation" that can be queried just like a table. I do wish someone would create a compile-to-sql language that adds variables and basic conditional support. I think T-SQL…
I don't think SQL does compose well. Queries aren't first-class values in SQL. I can write a query that queries the result of another query, but I can't store a query and then pass that somewhere to query from.
Check the example at the beginning of https://www.postgresql.org/docs/13/queries-with.html
Re: Prisma – ORM for Node.js and TypeScript
#225Earlier quoted context omitted.
While depending on a live DB for testing isn't great, why not just blow away database state after every test by running TRUNCATE / DELETE against all tables? DELETE especially is very fast (couple ms) if you're not inserting large amounts of data during your test runs.
1) You can't run tests in parallel. 2) It is at least an order of magnitude slower than not using a database at all. Combined this makes for very slow tests. Certainly for larger applications with thousands of tests. Having said that, I don't think there is a single right answer to the problem of testing applications that use a database and your suggestion still can be a valid solution.
Parallelizes quite well when we test the engines at Prisma...
Re: Prisma – ORM for Node.js and TypeScript
#226Earlier quoted context omitted.
I think SQL gets a lot of undeserved praise that I’m having a difficult time understanding. The only impressive thing about SQL is its prevalence but that’s a pretty poor yardstick unless one thinks that an appeal to popularity is an indicator of quality. Now let me count the ways in which SQL is bad: - it composes poorly due to its unwieldy cobolesque syntax - it is a leaky abstraction revealing a lot of underlying…
Would be interested in hearing what database and query language you think are better?
Re: Prisma – ORM for Node.js and TypeScript
#227Earlier quoted context omitted.
> SQL is an impressive technology and has stood the test of time! Yet, we claim that it's not the best tool for application developers who are paid to implement value-adding features for their organizations. I'm not sure about that. We've recently switched from JavaScript based querying code to mostly raw SQL, and we've reduced our code to about 25% of what it was, and it's much simpler to understand than it was befo…
> We've recently switched from JavaScript based querying code to mostly raw SQL Curious what your use case is, because in every codebase I've worked on, people pretty quickly get tired of writing out SELECT * FROM [table] WHERE id=? and UPDATE [table] SET field=? and looping over database cursors all day, and you end up with a half-done, buggy non-ORM.
But for anything more complex than that (e.g. SELECT queries joining several tables) we're using knex.raw so the query itself is raw SQL where we're very much thinking in the relational model rather than in terms of objects.
Re: Prisma – ORM for Node.js and TypeScript
#228“ Application developers should care about data – not SQL” Anyone who has been bitten by an ORM generating inefficient SQL (and subsequent having to learn and care about SQL) knows the above not to be true.
Re: Prisma – ORM for Node.js and TypeScript
#229Earlier quoted context omitted.
> We've recently switched from JavaScript based querying code to mostly raw SQL Curious what your use case is, because in every codebase I've worked on, people pretty quickly get tired of writing out SELECT * FROM [table] WHERE id=? and UPDATE [table] SET field=? and looping over database cursors all day, and you end up with a half-done, buggy non-ORM.
We're using knex.js, so we're not messing around with database cursors (we get an array of objects), and we don't have to write out the columns for inserts/updates. We also sometimes use the knex query builder for super trivial selects from a single table. But for anything more complex than that (e.g. SELECT queries joining several tables) we're using knex.raw so the query itself is raw SQL where we're very much thin…
Re: Prisma – ORM for Node.js and TypeScript
#230Food for thought if prisma.io team is watching.
[0] https://www.paloaltonetworks.com/company/press/2019/palo-alt...
[1] https://blog.paloaltonetworks.com/2019/11/cloud-prisma-cloud...