101–110 of 112 posts
Does it have migrations yet? I'd like to give Prisma a try, but if there's no sane way to change my schema (part of my daily backend workflow) then it's less interesting, no matter how nice the API is. For now I'll stick with Sequelize.
I'm very glad to see work being done on db bindings, but until migrations reach the level of django/active record, I won't be using postgres + node.js seriously (again).
Does it have migrations yet? I'd like to give Prisma a try, but if there's no sane way to change my schema (part of my daily backend workflow) then it's less interesting, no matter how nice the API is. For now I'll stick with Sequelize.
Earlier quoted context omitted.
That sounds awful, and completely different from my experience with ORMs. My experience has almost exclusively been entity framework, which despite having some warts (rank over partition queries are impossible) has been a very pleasant experience. One advantage is the additional domain language is also the language of array/list manipulation, and not having to maintain any encoders/decoders (I honestly don't know wha…
Interesting, coming from Eloquent ORM (PHP), I hated Entity Framework. It seemed to want to do far too much clever stuff (like save an entire object graph at once), and didn't have nearly as many escape hatches as I'm accustomed to (Eloquent will let you inject raw SQL nearly anywhere). I've had positive experiences like ORMs, but only when they are thin layers over the underlying SQL.
Entity framework follows the unit of work pattern from gang of four, and if I remember correctly eloquent follows the active record pattern.
When I started I found the active record pattern much more intuitive, but I prefer the unit of work pattern now. Mostly because I think unit of work works better with transactions/constraints then active record pattern.
Earlier quoted context omitted.
I generate Typescript types from my database ([link redacted]) which gives me type safety on back- and frontend without relying on an ORM. I am curious about Prisma but I don't see any advantage to it from my quick skimming.
What do you use to write the queries? Some query builder?
Not sure I 100% agree with their problem statement. > the problem: Working with databases is difficult Working with databases is a relatively solved problem. You can access them from just about any language on any platform. A more accurate statement would be: choosing the right access method to work with databases is difficult.
> A more accurate statement would be: choosing the right access method to work with databases is difficult. For me, it's the fiddly bit where you interface between the programming language and the database is a PITA.
Earlier quoted context omitted.
It's my impression that hasura caters more to (also) those that need to integrate with an existing database and schema, possibly with views and functions - would that be accurate? Does it make sense to slap prisma on top of an existing g production database?
(I'm from Hasura). It was a definitely a design goal for us to make the existing production database use-cases as seamless as possible. Instead of adding a new DSL on top of the database, Hasura maps much of the DML subset of SQL over to GraphQL (tables, views, functions) so that we're not re-inventing that bit and the translation is restricted to the "relation set" to "tree" transformation. json aggregation and json…
It is, but I've just been too lazy so far to actually do it.
Does it have migrations yet? I'd like to give Prisma a try, but if there's no sane way to change my schema (part of my daily backend workflow) then it's less interesting, no matter how nice the API is. For now I'll stick with Sequelize.
I'm very glad to see work being done on db bindings, but until migrations reach the level of django/active record, I won't be using postgres + node.js seriously (again).
Prisma Migrate is different from ActiveRecord migrations (which are very familiar with) because the DB schema is state-based. The Prisma schema file acts as source of truth and the DB schema will be migrated to match it.
Can you elaborate on what you would perceive as reaching the level of Django/ActiveRecord? I'd be interesting in specific aspects/items.
Earlier quoted context omitted.
Today's release unfortunately doesn't include our migration solution Prisma Migrate [1] yet. We totally understand that a lot of people want to get "database access" and "schema migrations" with the same tool/library, that's why we're focusing most of our engineering efforts on Prisma Migrate next and will hopefully be able to release that soon! However, we do see a lot of folks using third-party migrations (like kne…
Is there a plan for a higher-level migration API rather than just generating + executing raw sql strings?
Earlier quoted context omitted.
It's my impression that hasura caters more to (also) those that need to integrate with an existing database and schema, possibly with views and functions - would that be accurate? Does it make sense to slap prisma on top of an existing g production database?
It certainly make ssense to use Prisma with an existing database. In fact, Prisma is able to introspect your database and create a typesafe data access client for you. If you give it a try and have a database handy, I bet you can have it up and running in less than 10 minutes.
Regarding prisma, I see my impression was off a bit from talking with our team that used prisma in a green field project with migrations quite happily. And I somehow forgot that migrations are still marked experimental and are kind of new.
https://www.prisma.io/docs/reference/tools-and-interfaces/pr...
Prisma's architecture seems novel and ... a little strange to me. It works by running a Rust engine as a subprocess and then communicating with the engine from JS land over a non-spec compliant GraphQL API. The engine holds the actual databae connection pool and does all the SQL generation and data marshalling. See https://www.prisma.io/docs/reference/tools-and-interfaces/pr... for more info on this arrangement. It h…
Thank you for writing this up hbrundage - that's a pretty good summary. I'm the co-founder of Prisma, so should be able to answer some of your questions :-) Prisma has a Query Engine written in Rust, and a language binding for each target language. Currently we only support JavaScript and TypeScript, but a binding for Go is already in the works. As Sytten alluded to, this split allow us to write and test all the logi…
With respect to building out a big-boy operational datastore -- I think that's really cool. It'd be nice for me to be able to use something like TAO or EVCache or what have you without having to build it all myself, that's for sure. I understand why Prisma's API is constrained compared to a regular relational database in order to support those needs. That said, I think that the very best (and certainly most sell-able) Application Data Platform doesn't require adopters to drop key abilities or semantics they are used to in order to switch away from a normal database. I think those semantics only need to be dropped at the kind of scale which very few Prisma users are ever going to reach, yet they pay the productivity penalty for those missing semantics from the very first moment they begin using the tool.
Yes, you can do a lot of the same things you might want to do with transactions with nested or batch operations, but, not everything. For example, Rails' transactional testing feature is battle tested and seemingly well loved by the community, and currently impossible with Prisma. Instead, you must use a slower and more error-prone database cleaner tool. Another example would be a bank style database with double entry accounting. You want to decrement one account by a certain amount and increment another account by a certain amount transactionally, but only if the from account has a total greater than the certain amount. `SELECT FOR UPDATE` to the rescue in Postgres, but negative account balances with Prisma.
Teaching developers to not hold transactions open for a long time, or to use smart, efficiently implemented nested inserts is a good thing without a doubt, but you could still do that education while preserving transaction semantics. Devs have been used to having those since the 70s. The two aren't in conflict if you ask me. It would make your life harder, that's for sure, but it would make my life as a potential user easier, and remove one argument for not switching over.