I'm with the product team at Prisma, currently focusing on migrations.
You are right about the fact that declarative migrations introduces some design challenges that can be hard to solve. In the current version of Prisma Migrate, changes to the declarative schema file are translated to auto-generate incremental migration files.
We have a few ideas for how we can improve our system to better deal with these challenges. Please feel free to follow along or check back in a few months if you are interested in how we solve (or not?) these problems! :)
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 behind a feature flag (batch transactions, not long running transactions).
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.
Not yet indeed. Prisma doesn't support long running transactions and advocates for alternative ways. We're preparing a post on the topic soon, and will improve the means for those alternatives.
Also, no mention of aggregations, or if someone could point me to it?
As far as typed query builders go, even though things like JOOQ are simply amazing, but I fear that the query building approach has not really caught on for database access and people seem to prefer "object oriented" methods like ORMs.
People are scared of SQL or they want to use their objects for data access, business logic and views at the same time (leading to bad architecture and headaches), or they come from Nosql world, or they want a shiny new tool, or they do not understand features of their used db well, or because “everybody is using ORM zyz”... Just from the top of my head, there are probably more.
Does the commercial offering from Gatsby offer hosting? I couldn't figure it out from the https://gatsbyjs.com page.
Gatsby and NextJS (Vercel) are both backed by CRV[1,2]. It seems like a fairly competitive overlap. Would love to hear takes from folks on HN about the feasibility and comparison of Gatsby's and Vercel's business models and competitive overlaps.
Haven't really used Gatsby but vercel is magical. Like once you link up your GitHub repo, the fact that everything works so smoothly is delightful. A lot of other platforms try to compete with vercel on ease of use (heroku) but doesn't even come close. Next.js + vercel seems like cheating honestly
No Prisma is not like JOOQ. We are happily using JOOQ internally at Prisma so i happen to know. The main differences in my opinion are:
- JOOQ is a SQL Query Builder which is typesafe in regards to the fact that you cannot make SQL syntax errors in your query. However you can still write queries that are e.g. using a table that does not exist. In contrast the Prisma Client gets generated for all your tables and columns and this error is impossible. You also don't need to do any mapping from SQL result sets to your application models.
- JOOQ is about SQL. Prisma is not only about SQL but also any other kind of database. Prismas architecture is comprised of a database agnostic core and database specific connectors. Therefore it can connect to any database for which a connector exists. Right now we have connectors for Postgres, MySQL and MongoDB. More are in the works and in the future people will be able to implement their own connectors :-)
- Prisma has a migration system but JOOQ does not have one.
You're modifying existing state so it has to be incremental.
I'm curious to see how Prisma plans to handle these real-world use-cases.