61–70 of 114 posts
a similar open source project is Postgraphile: https://www.graphile.org/postgraphile/ I've used it on 3 non-trivial projects with great success
I find it odd that they say "Prisma is ready for production", but "Prisma Migrate is currently in an experimental state and should not be used in production environments". Having a robust migration management system is one of the primary things I look for in an ORM/database management tool in general. The only constant is change when it comes to business requirements, and having the ability to easily and safely chang…
As a counter example, Django was "ready for production" for ages before a third-party migration app (South) came along, let alone built-in support
I'm not saying it's not important or that Prism is fine without it. I wouldn't choose software without a tried, tested migration strategy available. Just... To a lot of people I've worked with, migrations are a nice-to-have that will probably never happen.
While the implementation certainly seems very nice, the ideas behind Prism 2 aren't particularly new, or unique for that matter. For example the .NET ecosystem already has (for a long time) most of the stuff that is presented as being uniquely offered by Prism: generated database clients (LINQ-to-SQL, Entity Framework), generated data models (EF POCO's), type-safe queries (LINQ) etc.
Everything is being reinvented from scratch in the JS world. The insistence on unifying into one language means that a lot of tried tested and true has been tossed aside and it's all being rebuilt sometimes with dubious benefit.
I mentioned this the last time, but I find it surprising that the Prisma ORM doesn't support transactions or aggregations? Any thoughts from the Prisma team? It kind of seems like table stakes. I commented on this previously as well: https://news.ycombinator.com/item?id=23467427
How could I write any serious ecommerce/financial product with Prisma without transactions? Thats is crazy. Sticking with Postgres and plain ol' SQL!
I’m not seeing why I’d use this over sql. Can someone please enlighten me as I find this to be much more gobbledegook than sql.
If you are a grumpy HN troll, then Prisma might not be for you, and that's okay. SQL is great for many cases, and you might not need to expand your horizon.
If you do choose to look into Prisma and have serious thoughts on how we could improve, then I would love to get on a call to talk about it (contact info in bio).
While the implementation certainly seems very nice, the ideas behind Prism 2 aren't particularly new, or unique for that matter. For example the .NET ecosystem already has (for a long time) most of the stuff that is presented as being uniquely offered by Prism: generated database clients (LINQ-to-SQL, Entity Framework), generated data models (EF POCO's), type-safe queries (LINQ) etc.
Some of the ideas we've built into Prisma are certainly inspired by tools in other languages and we've looked a lot at LINQ and the C# ecosystem in general as we designed Prisma! However, I believe that one thing that sets Prisma apart is the architecture with a _query engine_ [1] (implemented in Rust) that takes care of query planning and execution on top of which we can add lightweight, language-specific layers to…
Is the idea that Prisma might be backing on to multiple databases and therefore needs another planning layer? If so, wouldn't this need to be very specific to the database and schema – knowing that particular fields in one database refer to entities in another? Does Prisma tackle this? How?
I find it odd that they say "Prisma is ready for production", but "Prisma Migrate is currently in an experimental state and should not be used in production environments". Having a robust migration management system is one of the primary things I look for in an ORM/database management tool in general. The only constant is change when it comes to business requirements, and having the ability to easily and safely chang…
As a counter example, Django was "ready for production" for ages before a third-party migration app (South) came along, let alone built-in support
Earlier quoted context omitted.
Everything is being reinvented from scratch in the JS world. The insistence on unifying into one language means that a lot of tried tested and true has been tossed aside and it's all being rebuilt sometimes with dubious benefit.
Same thing happened with Python for data science in 2023-2015. ie reinvent SQL using Python DSL.
You can say all you want about how fast,optimized and superior SQL is, but the python experience is way better for almost any time you need to make sense of some data.
Earlier quoted context omitted.
How could I write any serious ecommerce/financial product with Prisma without transactions? Thats is crazy. Sticking with Postgres and plain ol' SQL!
Prisma supports transactions through the `prisma.transaction` API. This allow you to perform multiple DB actions in a single request and gives you an all-or-nothing semantic.
IIUC, a "batch" request is run in a transaction.But if I need to run business logic in the middle of requests that's not supported?
While the implementation certainly seems very nice, the ideas behind Prism 2 aren't particularly new, or unique for that matter. For example the .NET ecosystem already has (for a long time) most of the stuff that is presented as being uniquely offered by Prism: generated database clients (LINQ-to-SQL, Entity Framework), generated data models (EF POCO's), type-safe queries (LINQ) etc.