Live data from Hacker News

Prisma – ORM for Node.js and TypeScript

prisma.io

221–230 of 260 posts

Re: Prisma – ORM for Node.js and TypeScript

#221

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…

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

#222

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…

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

currently staring at what's left in a large legacy rails/activerecord app figuring out what to do with. the suffering is real.

Re: Prisma – ORM for Node.js and TypeScript

#223
I'd still take Hibernate and Entity Framework over any of the Node ORMs I've seen, including Prisma. The former usually have the feature you need to generate the queries you want, but you just haven't read enough of the docs to understand how to do so. The latter straight up lack the functionality and lack sufficient docs.

Re: Prisma – ORM for Node.js and TypeScript

#224

Earlier 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.

Maybe the WITH statement and CTEs can help you, if I understood correctly your complaint.

Check the example at the beginning of https://www.postgresql.org/docs/13/queries-with.html

Re: Prisma – ORM for Node.js and TypeScript

#225
post #54

Earlier 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.

If you run postgres, make a schema per test and do a cascading drop to the schema after the test. Name the schema either by the test or with a random string. Same applies for SQL Server and on MySQL you'd do this with databases instead.

Parallelizes quite well when we test the engines at Prisma...

Re: Prisma – ORM for Node.js and TypeScript

#226
post #63

Earlier 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?

I think Datalog as implemented by Datomic has a much better syntax though I don't like Datomic per se.

Re: Prisma – ORM for Node.js and TypeScript

#227
post #193

Earlier 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.

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 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.

The answers is both. Devs cannot work on a system (involving "data") without knowing about that data/how it works/how it is structured and how to store and retrieve it. Pretending you can do one without the other leads to a boatload of issues in the medium and long term.

Re: Prisma – ORM for Node.js and TypeScript

#229
post #193

Earlier 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…

Ahh that makes more sense. My preference has been to use an ORM for your normal CRUD, but write more advanced queries using SQL (or sometimes just write the where clause using SQL, if the select is otherwise simple.) I am not a fan of query builders.

Re: Prisma – ORM for Node.js and TypeScript

#230
Maybe it's too late to change the name. When Palo Alto Networks acquired Twistlock (Container Scanning/Security products) 2 years ago [0], they folded it in & renamed it to Prisma Cloud [1].

Food 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...

Post reply on HN