51–60 of 114 posts
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.
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.
And at the end of the day all we do is select, insert, update and delete in some database.
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
Earlier quoted context omitted.
Is this meant for the average developer or for highly-scalable enterprises only? What is the problem with the current vast number of databases? I personally still use MySQL and MongoDB and don't have many complaints in regards to usability or performance.
Prisma is not a database. It is a modern way for application developers to work with all the databases they already use. The main benefit is improved developer experience due to automatic generation of types, which gives you full code-cpmpletion for your database queries in JavaScript and TypeScript.
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.
My first instinct was to say type safety, but you don't really get that with JS either way. Maybe it would be popular for new engineers that don't feel like learning SQL. Same reason why MongoDB got popular.
That may be a bit harsh, but I’d rather them learn something they can use forever rather than the flavor of the week. Additionally, by learning SQL, they’d be able to apply that domain knowledge to building out queries in the flavor of the week since you know some limitations of the underlying.
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
Transactions were actually included in the last release https://github.com/prisma/prisma/releases/tag/2.1.0 (search for `transactionApi`) in a specific form behind a feature flag (batch transactions, not long running transactions).
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
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
This time I can answer that some aggregations are in the current milestone: https://github.com/prisma/prisma/issues/2838 That could mean they will be available very soon. (If you are missing any other ones, please comment on that issue or create a new one!) Transactions were actually included in the last release https://github.com/prisma/prisma/releases/tag/2.1.0 (search for `transactionApi`) in a specific form behin…