15 ms·

Prisma 2.0 Beta: Type-safe Database Access

287 points by johnnyballgame 7y ago

nailer 7y ago
Is mongo support in yet? I tried the Prisma2 beta a couple of months ago and it was still on the way.
- etelsv 7y ago
  We do not have Mongo support in Prisma 2 at this point, but we have a GitHub issue to track it as a feature request: https://github.com/prisma/prisma/issues/1277 https://github.com/prisma/prisma/issues/1277
CraftThatBlock 7y ago
How does this compare to TypeORM? First time hearing about this project, and it looks interesting
- g_delgado14 7y ago
  - https://www.prisma.io/docs/understand-prisma/prisma-in-your-stack/is-prisma-an-orm https://www.prisma.io/docs/understand-prisma/prisma-in-your-... - https://www.prisma.io/docs/understand-prisma/data-modeling#data-modeling-with-orms https://www.prisma.io/docs/understand-prisma/data-modeling#d...
- nikolasburk 7y ago
  Nikolas from the Prisma team here. The most important thing to note here is that Prisma Client is not an ORM! [1] Prisma doesn't map classes to tables as ORMs do and therefore doesn't suffer from the object-relational impedance mismatch. Prisma Client queries return plain old JS objects, which makes it really easy to reason about queries and returned data. Prisma also has a query engine [2] that's implemented in Rust. This is being developed separately from the TS/JS layer above (so that in the future Prisma can support other languages as well). Prisma also generally provides stronger type safety than TypeORM. For example, you get full type safety even for partial queries [3], you can find an example for what this looks like in this video [4]. Let me know if you have more questions about this :) [1] https://www.prisma.io/docs/understand-prisma/prisma-in-your-stack/is-prisma-an-orm https://www.prisma.io/docs/understand-prisma/prisma-in-your-... [2] https://www.prisma.io/docs/reference/tools-and-interfaces/prisma-client/query-engine https://www.prisma.io/docs/reference/tools-and-interfaces/pr... [3] https://www.prisma.io/docs/reference/tools-and-interfaces/prisma-client/advanced-usage-of-generated-types https://www.prisma.io/docs/reference/tools-and-interfaces/pr... [4] https://youtu.be/LggrE5kJ75I?t=40 https://youtu.be/LggrE5kJ75I?t=40
  - pvg 7y ago
    In the first document, all the links in the comparison table link back to the document itself instead of the documentation for the things mentioned.
    - nikolasburk 7y ago
      Thanks, will get that fixed!
  - Scarbutt 7y ago
    and therefore doesn't suffer from the object-relational impedance mismatch. Prisma Client queries return plain old JS objects Is that really true? the data models are still different, relations vs js objects. Maybe you meant to say that Prisma hides and abstracts away the relational model, but the impedance mismatch is still there.
  - jbverschoor 7y ago
    You still map objects to relations.
    - sorenbs 7y ago
      - ORMs traditionally map classes to tables. - Prisma maps queries to structural types. This is a key distinction that the community will need to spend some time to really get an intuitive understanding for. I think you will realise that many of the problems we discovered when using classic ORMs (often described as impedance mismatch) does not apply to Prisma. But there are sure to be other problems that we will discover over time. I am looking forward to shake this out together with the broader community over the coming years.
  - heymartinadams 7y ago
    Nikolas, video [4] is still set to “private”, fyi.
    - nikolasburk 7y ago
- latchkey 7y ago
  Mikro ORM [1] is the new hot sauce over TypeORM and it is fantastic. [1] https://mikro-orm.io/ https://mikro-orm.io/
Sytten 7y ago
I have been using it for a new project and it really is awesome. I can't imagine going back to an ORM or another query builder now.
- efrafa 7y ago
  Been using it as well on a side project together with nexus and nexus-prisma and it's really a joy to work with.
  - tylerandersen89 7y ago
    Same we've been using Graphcool/Prisma 1 for 2 years. Has been single handedly the biggest reason for our speed of development. We absolutely love the generated types and automatic introspection, everything is just documented automatically, it's truly revolutionary.
kemcho 7y ago
Looks cool! Is there a business model around prisma?
- nikolasburk 7y ago
  We are planning to eventually add commercial cloud services to make Prisma/DB workflows easier (especially for teams and larger organizations). The current OSS database toolkit will remain free forever! More info here: https://www.prisma.io/docs/more/faq#how-much-does-prisma-20-cost https://www.prisma.io/docs/more/faq#how-much-does-prisma-20-...
g_delgado14 7y ago
Hi there, I'm a prisma 1 user and am wondering if there is thorough docs on how to transition over to prisma 2. Also what breaking changes or not-yet-implemented features of prisma1 should I be aware of. ---- Edit: I see there's a "I currently use Prisma 1, what should I do?" section. Any other info would be greatly appreciated.
- nikolasburk 7y ago
  Hey! We will provide upgrade guides and dedicated tooling [1] in the next couple of weeks to ensure a smooth transition for current Prisma 1 users! You can find more context on isprisma2ready.com. [1] https://github.com/prisma/prisma/issues/1937 https://github.com/prisma/prisma/issues/1937
WhitneyLand 7y ago
I don’t know why this is not getting more up votes it looks pretty cool. At first it may seem like yet another attempt to make database access easy while really making it more complex and harder to maintain. I haven’t tried this yet, but after reading a couple pages it looks more interesting than that. For example the fact that it relies on typescript knowledge which is already widespread, and the fact that it doesn’t require any server side technology to be installed is a huge advantage. I’m not sure how it feels in practice, if anyone has experience with it please chime in.
- Scarbutt 7y ago
  One headline is: Focus on your data – not on complex SQL queries Looks like just another SQL DSL trying to make you not learn SQL. TS's structural typing and plain SQL can get you far into a simpler/robust system IMO. Also, the "introspection" part of Prisma seems very crippled, Postgres has so many useful features for writing application code that it seems wasteful to just treat it as dumb data store.
  - nerdponx 7y ago
    Composability and encapsulation are both somewhat lacking in SQL and there are valid reasons to want to write queries in a different DSL that can be compiled to SQL.
  - jbverschoor 7y ago
    Just stop the anti-ORM bs. Most applications need simple select queries, and often want to walk the obejct / relation graph. Prism looks awesome, and has great TS support. If you want to concatenate sql for each frikking query, be my guest. I have better things to do with my time, such as responding to this kind of stuff. For "small" and "large" queries, just use the ORM. For "complex" queries, just use SQL.
  - david-cako 7y ago
    I find the process of writing database access functions annoying, and for the most part, arbitrary and repetitive. ORM functionality that bakes types/accessors, migrations, graphQL, and even infrastructure into your codebase is where it’s at. The fact that you are writing your models once and automatically exposing them as types in any project’s language is a huge value. I don’t need the same language everywhere, but I want types that plug together without hassle. Next generation “serverless” databases will fully abstract object mapping away. It’s tedious and arbitrary. Even indexing is relatively easy to automate. I am incredibly excited for what Apple is brewing up right now for developers.
johnnyballgame 7y ago
Tom Preston-Werner chose to include Prisma 2 in his new RedwoodJS project and it's been a pleasure to work with.
- salimmadjd 7y ago
  I'm very curious. Can you pleas share some specifics.
  - nikolasburk 7y ago
    https://twitter.com/mojombo/status/1244877311196856320 https://twitter.com/mojombo/status/1244877311196856320
  - johnnyballgame 7y ago
    https://redwoodjs.com/ https://redwoodjs.com/
  - RickS 7y ago
    the biggest recent HN discussion: https://news.ycombinator.com/item?id=22537944 https://news.ycombinator.com/item?id=22537944
- 40four 7y ago
  Looks nice, have not seen this. I'm more and more inclined to take a JAMstack approach with new projects, so RedwoodJS looks very interesting. I keep seeing Prisma pop it's head up every now and then and I've been curious. I looks pretty nice, maybe I'll start a toy project in Redwood and try them both out!
- samblr 7y ago
  >> Tom Preston-Werner chose to include Prisma 2 in his new RedwoodJS project Sorry to say, above comment is mostly cringe worthy! Having tried Redwoodjs, I should say at the moment Nextjs offers everything better.
  - Sytten 7y ago
johnnyballgame 7y ago
Will SQL Server databases be supported at some point?
- nikolasburk 7y ago
  We're indeed planning to broaden the support for various databases in the future (e.g. already looking into MongoDB and FaunaDB). If you have a specific DB in mind that you'd like to see supported, please open a feature request here: https://github.com/prisma/prisma/issues/new?assignees=&labels=&template=feature_request.md&title= https://github.com/prisma/prisma/issues/new?assignees=&label...
  - ceohockey60 7y ago
    Good to hear. Curious why Fauna is being looked into by your team, since it appears to be a much newer database (and also not open sourced AFAIK)? Mongo makes sense given its obvious popularity.
redka 7y ago
Does this work with pnpm since node_modules/@prisma/client changes based on the project it's in?
- pantharshit00 7y ago
  It works fine with pnpm. The client package has a postinstall hook that generates the client after you install it.
hleszek 7y ago
We started using Prisma 1 for our project and ran really fast into missing features that are really missing for a complete product. But with a few workarounds it was possible to make it work and is quite nice to use. Example of missing features: Primary key as a combination of two relational models: https://github.com/prisma/prisma1/issues/3553 https://github.com/prisma/prisma1/issues/3553 Database Constraints https://github.com/prisma/prisma1/issues/728 https://github.com/prisma/prisma1/issues/728 Cascading Deletes https://github.com/prisma/prisma1/issues/1262 https://github.com/prisma/prisma1/issues/1262 Upsert https://github.com/prisma/prisma1/issues/2194 https://github.com/prisma/prisma1/issues/2194 On delete restrict https://github.com/prisma/prisma1/issues/2701 https://github.com/prisma/prisma1/issues/2701 Mutation CreateOrConnect https://github.com/prisma/prisma1/issues/3724 https://github.com/prisma/prisma1/issues/3724 Improving performance with Indexes https://github.com/prisma/prisma1/issues/1300 https://github.com/prisma/prisma1/issues/1300 Multiple field unique constraint https://github.com/prisma/prisma1/issues/171 https://github.com/prisma/prisma1/issues/171 Interface types https://github.com/prisma/prisma1/issues/83 https://github.com/prisma/prisma1/issues/83 Embedded Types https://github.com/prisma/prisma1/issues/2836 https://github.com/prisma/prisma1/issues/2836 Declarative support for multi-field unique constraints https://github.com/prisma/prisma1/issues/1237 https://github.com/prisma/prisma1/issues/1237 Support union types https://github.com/prisma/prisma1/issues/165 https://github.com/prisma/prisma1/issues/165 Transactions for multiple mutations https://github.com/prisma/prisma1/issues/74 https://github.com/prisma/prisma1/issues/74
- nikolasburk 7y ago
  Hey! Thanks a lot for sharing this, a lot of the features you mention here are already possible with Prisma 2.0 (or will be in the future). Would love to hear your thoughts on the new version :)
fataliss 7y ago
So is that some sort of "ActiveRecord" for Javascript? It looks pretty darn cool.
propelol 7y ago
How does it differ from Hasura?
- itake 7y ago
  It has a lot more features (and is more complicated).
- nikolasburk 7y ago
  Prisma and Hasura are very different! Prisma is a database toolkit that's used by application developers to develop server-side applications in Node.js and TypeScript (e.g. REST APIs, microservices, gRPC calls, GraphQL APIs, ..., anything that talks to a database). The main tool Prisma Client is a query builder that's used to programmatically send queries to a database from Node.js/TS. Hasura is a "GraphQL-as-a-Service" provider that generates a GraphQL API for your database. This GraphQL API is typically accessed by frontend developers. That setup can be great when your application doesn't require a lot of business logic and the CRUD capabilities that are exposed in the GraphQL API fit your needs (though I believe you can add business logic in Hasura by integrating serverless functions). With Prisma, you're still in full control of your own backend application and can choose whatever tech stack you like for developing it (as long as it's Node.js-based, though Prisma Client will be in available in more languages the future)! By the way, we also love GraphQL. We're currently brewing a new "GraphQL application framework" that can be used on top of Prisma. That way it will be possible to auto-generate resolvers for Prisma models to reduce the boilerplate you need to write, while still keeping the full control of your GraphQL schema. You can learn more about this here: https://www.nexusjs.org/#/ https://www.nexusjs.org/#/
  - gavinray 7y ago
    I want to point out a defining characteristic between Hasura and Prisma: While Hasura does work to auto-generate a GraphQL API from an existing database, it also has a web console that lets you build your database models and relationships, plus permission logic and authorization point-and-click. Custom business-logic outside of the CRUD it generates is done by writing HTTP endpoints that you can wrap as "Actions", which it generates GraphQL types and resolvers for as part of it's schema. IE, you will want to define an API endpoint for login/signup, and declare these as "Actions", which you can then query from Hasura's schema. An SDK/toolkit can be auto-generated from the GraphQL schema Hasura produces using graphql-code-generator, giving you strongly-typed query/mutation/subscription components in your desired frontend framework (IE React/Vue/Angular + Apollo/urql etc.) Scheduled tasks/cronjob functionality is under development as well. Prisma gives you a "finer grained" set of tools to "build" an application with, where Hasura kind of just hands you the whole thing (though in an opinionated fashion).
rlili 7y ago
Is real-time subscriptions on the roadmap? It's the most killer feature of Hasura and Postgraphile IMO.
- nikolasburk 7y ago
  Nikolas from Prisma here, a realtime API for Prisma is certainly on our roadmap – as Prisma doesn't provide a GraphQL interface, this most likely will not come in the form of GraphQL subscriptions though but another (programmatic) realtime API. However, using Nexus [1] on top of Prisma, you'll be then be able to turn Prisma's realtime API into GraphQL subscriptions. All of this is quite a bit further down the road, but certainly on our radar and part of future plans! We have an open feature request for that here: https://github.com/prisma/prisma/issues/298 https://github.com/prisma/prisma/issues/298 [1] https://www.nexusjs.org/#/ https://www.nexusjs.org/#/
- hleszek 7y ago
  You can put an apollo server on top of prisma and then you can do the subscriptions yourself with a pubsub (redis in our case)
ricardobeat 7y ago
Was really excited about this until I got to "smart node module". Isn't changing the contents of a package in node_modules going to break any kind of caching, de-duplicating etc? In my current project we install node_module` ahead of time and bake it into a docker image, it is quite common.
- codegladiator 7y ago
  Is there any other framework or library using these "smart" node_modules ? I never noticed.
  - nikolasburk 7y ago
    I don't believe so, this term was coined by one of our community members and we really liked it and decided to adopt it to distinguish Prisma Client conceptually from "conventional" (for lack of a better term) node modules.
    - eyelidlessness 7y ago
      Was there consideration of using something like schemats[1] and allowing users to specify where they want to store the types for their schema? Storing them in `node_modules` is extremely unidiomatic and probably rules this library out for me even though it's otherwise attractive at first glance. [1]: https://github.com/SweetIQ/schemats https://github.com/SweetIQ/schemats
      - nikolasburk 7y ago
        You can specify where you want to generate Prisma Client yourself, `node_modules` it's just the default. See my response above: > Also note that you can actually generate Prisma Client into a different location [4], so if you prefer not to have it in node_modules, that's totally possible as well. [4] https://www.prisma.io/docs/reference/tools-and-interfaces/prisma-client/generating-prisma-client#specifying-the-target-location-for-prisma-client https://www.prisma.io/docs/reference/tools-and-interfaces/pr...
eitland 7y ago
Edit: please read nikolasburk's answer below which makes a lot of sense. The docs weren't an attempted attack on all ORMs but rather a description of problems with certain Javascript ORMs. My original post: This looked interesting at first but this reads like someone either don't know a thing about JPA and Entity Framework or are deliberately misrepresenting them: > ORMs are libraries that map tables in your database to classes in your programming language. Prisma on the other hand is an auto-generated query builder that exposes queries which are tailored to your models. All Prisma Client queries return plain old JavaScript objects. Yep, tables maps to classes, but guess what gets returned? Plain Old Java (or CLR) Objects. And guess what: Thanks to those languages well thought out design and extensive metaprogramming abilities this can all be done without making up a new language also. This is probably the harshest I've been here on HN, but smearing good solutions really doesn't sit well with me.
- nikolasburk 7y ago
  Hey, thanks a lot for the feedback (and I've seen harsher words on HN, so no worries)! I wrote most of the docs, so more than happy to take any feedback to see where it can improved! What I'm mostly trying to refer to are ActiveRecord style ORMs in the Node.js ecosystem (such as Sequelize and TypeORM). With those libraries, you often have model objects that can get really complicated to work with, these are not plain objects but implement lots of additional behaviour for storage and retrieval of data, often times business logic as well. Compared to that, working with plain objects (which are statically and structurally typed) is a fundamentally different approach that's hopefully easier to reason (at least that's what I've found from my personal experience).
  - eitland 7y ago
    Ok, thanks for replying. I've been busily trying to reword my post since talking down to people who stand up and make things really isn't my thing either. I guess your explanation here makes a lot of sense - I don't know much about Javascript ORMs.
  - eropple 7y ago
    I don't really understand the claim you're making here--you have to go out of your way in TypeORM to get ActiveRecord objects instead of plain JavaScript objects. The happy path is pretty firmly in data-mapper territory; as an example, for all the shade I will happily fling NestJS's way they just hand you a Repository and tell you to get on with your day. There's also stuff like Objection.js (which works well in TypeScript), too. I don't dislike Prisma, but the framing is really strange to me.
zaiste 7y ago
Those, who prefer a more old-school approach, may find PgTyped [1] interesting: you write SQL and you have typings in TypeScript. Still very alpha, but promising. I'm working on integrating PgTyped into Huncwot [2] [1]: https://github.com/adelsz/pgtyped https://github.com/adelsz/pgtyped [2]: https://github.com/huncwotjs/huncwot https://github.com/huncwotjs/huncwot
zeroz 7y ago
Looks very interesting. At the moment we're using a Node.js + Postgres + Sequelize ORM [1] + Express setup in production and are very happy. All lot of features and very robust setup. Any production ready experience with Prisma? [1]: https://sequelize.org/v5/ https://sequelize.org/v5/
kemcho 7y ago
I LOVE massivejs[1], a query builder type library for Postgres in nodejs. Is prisma2 like massivejs but for typescript? If someone’s tried both, would love a quick comparison :) [1] https://massivejs.org/ https://massivejs.org/
- nikolasburk 7y ago
  Massive is great and we certainly took some inspiration from it (in fact we're friends with Dian, the author of Massive and are fans of her works). The level of type-safety when using Prisma Client with TypeScript is indeed a major factor that sets Prisma apart from other DB libraries in general (not Massive in particular). Would also love to hear what other people think of the two in comparison! :)
- zeroz 7y ago
  That's why I love HN! One published new solution and a whole tree of wonderful comments about related tech.
nojvek 7y ago
The fact that the returned objects are plain old javascript objects (POJOs) that's nice. The smart module bit, it's a bit scary. basically all I want is a lightweight layer that exposes a promise api to deal with different databases in a uniform manner. 1) sync to schema.json (this json file contains info of all tables, their columns, indices and foreign keys). I can sync to db or from db. This lets me have my state of schema committed to git, and easily move from dev -> staging -> prod. Django migrations are a giant pain in the ass. Don't do smart fancy node modules either. 2) autogenerated typescript types, this are nice. But again don't do fancy node modules, have the typescript types committable to git repo. It makes it easy to diff and bisect when things fo awry. 3) Super light weight Object -> sql. Access foreign relationships as promises (always). Make it very easy to debug the generated sql for perf reasons. Django does some bits well but it's insanely slow at times. Doing things with raw sql should be just as fast as using a library.
- nikolasburk 7y ago
  Prisma Client is generated into node_modules by default (because that's the most familiar thing for JS/TS devs), but you can specify any target location you like for it: https://www.prisma.io/docs/reference/tools-and-interfaces/prisma-client/generating-prisma-client#specifying-the-target-location-for-prisma-client https://www.prisma.io/docs/reference/tools-and-interfaces/pr...
  - nojvek 7y ago
    getting a `Not Found`
phiresky 7y ago
This seems to be solving mostly the same problem as the following libraries: [1] https://github.com/phiresky/ts-typed-sql https://github.com/phiresky/ts-typed-sql [2] https://github.com/Ff00ff/mammoth https://github.com/Ff00ff/mammoth [3] https://github.com/AnyhowStep/tsql https://github.com/AnyhowStep/tsql [4] https://github.com/travigd/vulcyn https://github.com/travigd/vulcyn A query in one of those looks like the following: const rows = await select(list.id, list.createdAt) .from(list) .where(list.createdAt.gt(now().minus(`2 days`)).or(list.value.eq(0))) .limit(10); The resulting type of `rows` is inferred by TypeScript to the corresponding correct type (`{id: string, createdAt: Date}`) Prisma solves the problem by generating code, while all of these do it completely in type-level within typescript. Prisma also seems to introduce its own query language, while the above linked libraries stay closer to SQL. [1] was written by a friend of mine and I'm using it in production to great success. I wouldn't recommend it though because it has repeatedly broken with new TypeScript updates since it uses very complex type structures and the dev has basically given up on it due to the complexity. [2] is probably the most production-ready, though it has some design choices I'm not sure about. [3] is the most well-designed, and can handle complex scenarios (including differentiating between join types etc). But it's incomplete so far. [4] I have not used. Pure type-level has the advantage of not adding a compile-step and keeping everything in a tool you already know. But all of the above have the disadvantage that the resulting type structures are very complex - most TS devs would have a hard time understanding the internals of the libraries and the resulting type errors can be unreadable. They can also cause the TS compiler to slow down significantly (in the past [1] had exponential compile time when adding a new column, though this has been fixed). Also, since the TS compiler uses heuristics in multiple places and the type system is not sound, Microsoft has introduced regressions that have broken [1] in every other release.
- adsharma 7y ago
  This doesn't work well when you have lots of queries that require a self-join. Get me a friend of a friend of a friend who joined 2 days ago. https://github.com/facebookexperimental/fquery/blob/master/tests/test_operators.py https://github.com/facebookexperimental/fquery/blob/master/t...
- timmy-turner 7y ago
samblr 7y ago
I was really excited when Prisma1 came out. It would be understatement to mention that Prisma1 was way overpromised and nothing ever materialised. With Prisma2, honestly disappointed as it is too little to show for. This is an ORM like library that supports only couple of databases with database migrations still in experimental state with broken links for workarounds[1] Also Prisma2 has half of the features at 'No / Not yet' supported state - https://www.prisma.io/docs/reference/database-connectors/database-features https://www.prisma.io/docs/reference/database-connectors/dat... Well makes me wonder what's wrong with TypeORM which supports 8 different databases with full feature support and migrations that work! [1] https://www.prisma.io/docs/reference/tools-and-interfaces/prisma-migrate https://www.prisma.io/docs/reference/tools-and-interfaces/pr... Data Validation Cascading delete Cascading update Renaming existing table Renaming existing column
- nikolasburk 7y ago
  > I was really excited when Prisma1 came out. It would be understatement to mention that Prisma1 was way overpromised and nothing ever materialised. While I can understand your sentiment, I don't think this is quite true! We've seen a number of companies very successfully adopt Prisma 1 – ultimately we realized though that the vision of building a new way for application developers to access their database can't be built on top of the JVM. At that point, we needed to make a tough judgement call and decided to rewrite Prisma in Rust. Needless to say that this was quite a challenge, but our engineers have done an absolutely outstanding job of managing this rewrite. We certainly had a number of tough learnings, especially when it came to the variety of different DB schemas out there that we needed to support with our introspection. I'm really proud of the result though, we've built a strong and stable foundation that allows us to expand the functionality of our tools over time – this would not have been possible without the rewrite! > With Prisma2, honestly disappointed as it is too little to show for. This is an ORM like library that supports only couple of databases with database migrations still in experimental state with broken links for workarounds[1] Please recall that we're just launching into Beta. As I said, we now have the foundation to expand the functionality of our tools! You'll see a lot of exciting improvements and new tools from Prisma over the next few months! Sorry about the broken links, I'm in the process of fixing most of them! In this case, the links point to the "Guides > Database workflows"-section which contains a number of helpful step-by-step tutorials for performing certain schema migrations (e.g. cascading deletes [1]) and using those with Prisma Client. (While these features are not supported by Prisma Migrate yet, you can still configure them in your DB and use Prisma Client for DB access). [1] https://www.prisma.io/docs/guides/database-workflows/cascading-deletes/postgresql https://www.prisma.io/docs/guides/database-workflows/cascadi...
alde 7y ago
This looks great and should surely cover most of the CRUD needs of simpler apps and hopefully even more. On the other hand, in my experience such complicated abstractions eventually leak, especially due to the complicated nature of the relational model and modern SQL. For developers not keen on adding a thick indirection layer between the app and the DB, I have been trying to make raw SQL easier and more reliable to use directly in TS with PgTyped[1]. In general, I think most people are more than glad to use raw SQL solution instead of a mapper as long as it has: 1) Realtime parameter/result type inference in their language of choice. 2) Has autocomplete and validation in their IDE 3) Is composable, allowing to join queries/sub-queries.. So far I have been able to implement SQL-in-TS type inference in PgTyped[1] with autocomplete and validation on the way. [1]: https://github.com/adelsz/pgtyped https://github.com/adelsz/pgtyped
- nikolasburk 7y ago
  pgtyped looks awesome, fantastic work! We're huge fans of type-safety at Prisma so anything that makes working with DBs type-safe is right down our alley! :D I think one thing that distinguishes Prisma (on the longer run) from a library like pgtyped is that Prisma will enable more database workflows than just database access. With Prisma Migrate, you can alter your DB schema and keep a migration history, Prisma Studio will enable lots of DB workflows on a GUI level, and Prisma Cloud will have great integrations for teams and larger scale organizations eventually. All that being said, because Prisma is a DB toolkit, you can also pick and choose any tools you like from it. Nothing would e.g. speak against using Prisma Migrate to run your schema migrations but keep accessing your DB with pgtyped, in fact I think this would be an awesome combination :)
heymartinadams 7y ago
I’ve been using Prisma in development and highly recommend it. There’s nothing like it out there!
adsharma 7y ago
Why generate types from a query when you can write a schema for your objects and then write queries where types can be inferred based on object types and query constructs? Some ideas from a recently open sourced project: https://github.com/facebookexperimental/fquery/blob/master/tests/test_operators.py https://github.com/facebookexperimental/fquery/blob/master/t...
andy_ppp 7y ago
It's alright isn't it to get something done fast, until this huge amount of code that you will never understand bites you in the ass. I'm secretly rewriting an API written in Prisma 1 into something lower level that actually allows me to write database queries, optimise what is going on, look into the simple underlying abstractions if things go wrong and essentially produce something I can reason about without just hoping nothing goes wrong under the hood. Apollo codegen is what you want if you'd like your Typescript frontend to be consuming the API in a typesafe way.
- crubier 7y ago
  You might want to have a look at Postgraphile. It is nice
beart 7y ago
I wish I was not stuck on Ms SQL server. The JS ecosystem tends to ignore it or treat it as a second class citizen. Would love to check this out otherwise.
ronlobo 7y ago
Makes sense, non-type-safe language, we can push type safety guarantees to the persistence layer by coupling the domain models to the type-safe data models.
crubier 7y ago
Why on earth did Prisma take the choice to move away from a brilliant automatic GraphQL backend as a service to some kind of weird ORM? Prisma became relevant during their Prisma 1 time, it was one of the first solutions to automatically generate GraphQL endpoints from DB schemas. It only had to keep going this way to lead the whole market. But they chose not too, and competing solutions such as Graphile beats prisma 1 so much now. Meanwhile they have been stuck for 2 years in their new weird direction of Prisma 2, with no results to show for, and no clear vision. The GraphQL server is gone, even though it was central to their product. Who cares about yet another ORM? I can generate types from any GraphQL endpoint automatically anyway!
timmy-turner 7y ago
Not getting warm with any query/ORM library out there. My own take of interfacing with an SQL database with Typescript: a query generator that uses mapped types a lot to infer result set types from queries and a schema file. https://github.com/hoeck/typesafe-query-builder https://github.com/hoeck/typesafe-query-builder Not sure if thats a good idea and if the Typescript inference even scales that well when using lots of tables. Any feedback and criticism would be welcome.

nailer 7y ago

Is mongo support in yet? I tried the Prisma2 beta a couple of months ago and it was still on the way.

etelsv 7y ago
We do not have Mongo support in Prisma 2 at this point, but we have a GitHub issue to track it as a feature request: https://github.com/prisma/prisma/issues/1277 https://github.com/prisma/prisma/issues/1277

CraftThatBlock 7y ago

How does this compare to TypeORM? First time hearing about this project, and it looks interesting

g_delgado14 7y ago
- https://www.prisma.io/docs/understand-prisma/prisma-in-your-stack/is-prisma-an-orm https://www.prisma.io/docs/understand-prisma/prisma-in-your-... - https://www.prisma.io/docs/understand-prisma/data-modeling#data-modeling-with-orms https://www.prisma.io/docs/understand-prisma/data-modeling#d...
nikolasburk 7y ago
Nikolas from the Prisma team here. The most important thing to note here is that Prisma Client is not an ORM! [1] Prisma doesn't map classes to tables as ORMs do and therefore doesn't suffer from the object-relational impedance mismatch. Prisma Client queries return plain old JS objects, which makes it really easy to reason about queries and returned data. Prisma also has a query engine [2] that's implemented in Rust. This is being developed separately from the TS/JS layer above (so that in the future Prisma can support other languages as well). Prisma also generally provides stronger type safety than TypeORM. For example, you get full type safety even for partial queries [3], you can find an example for what this looks like in this video [4]. Let me know if you have more questions about this :) [1] https://www.prisma.io/docs/understand-prisma/prisma-in-your-stack/is-prisma-an-orm https://www.prisma.io/docs/understand-prisma/prisma-in-your-... [2] https://www.prisma.io/docs/reference/tools-and-interfaces/prisma-client/query-engine https://www.prisma.io/docs/reference/tools-and-interfaces/pr... [3] https://www.prisma.io/docs/reference/tools-and-interfaces/prisma-client/advanced-usage-of-generated-types https://www.prisma.io/docs/reference/tools-and-interfaces/pr... [4] https://youtu.be/LggrE5kJ75I?t=40 https://youtu.be/LggrE5kJ75I?t=40
- pvg 7y ago
  In the first document, all the links in the comparison table link back to the document itself instead of the documentation for the things mentioned.
  - nikolasburk 7y ago
    Thanks, will get that fixed!
- Scarbutt 7y ago
  and therefore doesn't suffer from the object-relational impedance mismatch. Prisma Client queries return plain old JS objects Is that really true? the data models are still different, relations vs js objects. Maybe you meant to say that Prisma hides and abstracts away the relational model, but the impedance mismatch is still there.
- jbverschoor 7y ago
  You still map objects to relations.
  - sorenbs 7y ago
    - ORMs traditionally map classes to tables. - Prisma maps queries to structural types. This is a key distinction that the community will need to spend some time to really get an intuitive understanding for. I think you will realise that many of the problems we discovered when using classic ORMs (often described as impedance mismatch) does not apply to Prisma. But there are sure to be other problems that we will discover over time. I am looking forward to shake this out together with the broader community over the coming years.
- heymartinadams 7y ago
  Nikolas, video [4] is still set to “private”, fyi.
  - nikolasburk 7y ago
latchkey 7y ago
Mikro ORM [1] is the new hot sauce over TypeORM and it is fantastic. [1] https://mikro-orm.io/ https://mikro-orm.io/

Sytten 7y ago

I have been using it for a new project and it really is awesome. I can't imagine going back to an ORM or another query builder now.

efrafa 7y ago
Been using it as well on a side project together with nexus and nexus-prisma and it's really a joy to work with.
- tylerandersen89 7y ago
  Same we've been using Graphcool/Prisma 1 for 2 years. Has been single handedly the biggest reason for our speed of development. We absolutely love the generated types and automatic introspection, everything is just documented automatically, it's truly revolutionary.

kemcho 7y ago

Looks cool! Is there a business model around prisma?

nikolasburk 7y ago
We are planning to eventually add commercial cloud services to make Prisma/DB workflows easier (especially for teams and larger organizations). The current OSS database toolkit will remain free forever! More info here: https://www.prisma.io/docs/more/faq#how-much-does-prisma-20-cost https://www.prisma.io/docs/more/faq#how-much-does-prisma-20-...

g_delgado14 7y ago

Hi there, I'm a prisma 1 user and am wondering if there is thorough docs on how to transition over to prisma 2. Also what breaking changes or not-yet-implemented features of prisma1 should I be aware of. ---- Edit: I see there's a "I currently use Prisma 1, what should I do?" section. Any other info would be greatly appreciated.

nikolasburk 7y ago
Hey! We will provide upgrade guides and dedicated tooling [1] in the next couple of weeks to ensure a smooth transition for current Prisma 1 users! You can find more context on isprisma2ready.com. [1] https://github.com/prisma/prisma/issues/1937 https://github.com/prisma/prisma/issues/1937

WhitneyLand 7y ago

I don’t know why this is not getting more up votes it looks pretty cool. At first it may seem like yet another attempt to make database access easy while really making it more complex and harder to maintain. I haven’t tried this yet, but after reading a couple pages it looks more interesting than that. For example the fact that it relies on typescript knowledge which is already widespread, and the fact that it doesn’t require any server side technology to be installed is a huge advantage. I’m not sure how it feels in practice, if anyone has experience with it please chime in.

Scarbutt 7y ago
One headline is: Focus on your data – not on complex SQL queries Looks like just another SQL DSL trying to make you not learn SQL. TS's structural typing and plain SQL can get you far into a simpler/robust system IMO. Also, the "introspection" part of Prisma seems very crippled, Postgres has so many useful features for writing application code that it seems wasteful to just treat it as dumb data store.
- nerdponx 7y ago
  Composability and encapsulation are both somewhat lacking in SQL and there are valid reasons to want to write queries in a different DSL that can be compiled to SQL.
- jbverschoor 7y ago
  Just stop the anti-ORM bs. Most applications need simple select queries, and often want to walk the obejct / relation graph. Prism looks awesome, and has great TS support. If you want to concatenate sql for each frikking query, be my guest. I have better things to do with my time, such as responding to this kind of stuff. For "small" and "large" queries, just use the ORM. For "complex" queries, just use SQL.
- david-cako 7y ago
  I find the process of writing database access functions annoying, and for the most part, arbitrary and repetitive. ORM functionality that bakes types/accessors, migrations, graphQL, and even infrastructure into your codebase is where it’s at. The fact that you are writing your models once and automatically exposing them as types in any project’s language is a huge value. I don’t need the same language everywhere, but I want types that plug together without hassle. Next generation “serverless” databases will fully abstract object mapping away. It’s tedious and arbitrary. Even indexing is relatively easy to automate. I am incredibly excited for what Apple is brewing up right now for developers.

johnnyballgame 7y ago

Tom Preston-Werner chose to include Prisma 2 in his new RedwoodJS project and it's been a pleasure to work with.

salimmadjd 7y ago
I'm very curious. Can you pleas share some specifics.
- nikolasburk 7y ago
  https://twitter.com/mojombo/status/1244877311196856320 https://twitter.com/mojombo/status/1244877311196856320
- johnnyballgame 7y ago
  https://redwoodjs.com/ https://redwoodjs.com/
- RickS 7y ago
  the biggest recent HN discussion: https://news.ycombinator.com/item?id=22537944 https://news.ycombinator.com/item?id=22537944
40four 7y ago
Looks nice, have not seen this. I'm more and more inclined to take a JAMstack approach with new projects, so RedwoodJS looks very interesting. I keep seeing Prisma pop it's head up every now and then and I've been curious. I looks pretty nice, maybe I'll start a toy project in Redwood and try them both out!
samblr 7y ago
>> Tom Preston-Werner chose to include Prisma 2 in his new RedwoodJS project Sorry to say, above comment is mostly cringe worthy! Having tried Redwoodjs, I should say at the moment Nextjs offers everything better.
- Sytten 7y ago

johnnyballgame 7y ago

Will SQL Server databases be supported at some point?

nikolasburk 7y ago
We're indeed planning to broaden the support for various databases in the future (e.g. already looking into MongoDB and FaunaDB). If you have a specific DB in mind that you'd like to see supported, please open a feature request here: https://github.com/prisma/prisma/issues/new?assignees=&labels=&template=feature_request.md&title= https://github.com/prisma/prisma/issues/new?assignees=&label...
- ceohockey60 7y ago
  Good to hear. Curious why Fauna is being looked into by your team, since it appears to be a much newer database (and also not open sourced AFAIK)? Mongo makes sense given its obvious popularity.

redka 7y ago

Does this work with pnpm since node_modules/@prisma/client changes based on the project it's in?

pantharshit00 7y ago
It works fine with pnpm. The client package has a postinstall hook that generates the client after you install it.

hleszek 7y ago

We started using Prisma 1 for our project and ran really fast into missing features that are really missing for a complete product. But with a few workarounds it was possible to make it work and is quite nice to use. Example of missing features: Primary key as a combination of two relational models: https://github.com/prisma/prisma1/issues/3553 https://github.com/prisma/prisma1/issues/3553 Database Constraints https://github.com/prisma/prisma1/issues/728 https://github.com/prisma/prisma1/issues/728 Cascading Deletes https://github.com/prisma/prisma1/issues/1262 https://github.com/prisma/prisma1/issues/1262 Upsert https://github.com/prisma/prisma1/issues/2194 https://github.com/prisma/prisma1/issues/2194 On delete restrict https://github.com/prisma/prisma1/issues/2701 https://github.com/prisma/prisma1/issues/2701 Mutation CreateOrConnect https://github.com/prisma/prisma1/issues/3724 https://github.com/prisma/prisma1/issues/3724 Improving performance with Indexes https://github.com/prisma/prisma1/issues/1300 https://github.com/prisma/prisma1/issues/1300 Multiple field unique constraint https://github.com/prisma/prisma1/issues/171 https://github.com/prisma/prisma1/issues/171 Interface types https://github.com/prisma/prisma1/issues/83 https://github.com/prisma/prisma1/issues/83 Embedded Types https://github.com/prisma/prisma1/issues/2836 https://github.com/prisma/prisma1/issues/2836 Declarative support for multi-field unique constraints https://github.com/prisma/prisma1/issues/1237 https://github.com/prisma/prisma1/issues/1237 Support union types https://github.com/prisma/prisma1/issues/165 https://github.com/prisma/prisma1/issues/165 Transactions for multiple mutations https://github.com/prisma/prisma1/issues/74 https://github.com/prisma/prisma1/issues/74

nikolasburk 7y ago
Hey! Thanks a lot for sharing this, a lot of the features you mention here are already possible with Prisma 2.0 (or will be in the future). Would love to hear your thoughts on the new version :)

fataliss 7y ago

So is that some sort of "ActiveRecord" for Javascript? It looks pretty darn cool.

propelol 7y ago

How does it differ from Hasura?

itake 7y ago
It has a lot more features (and is more complicated).
nikolasburk 7y ago
Prisma and Hasura are very different! Prisma is a database toolkit that's used by application developers to develop server-side applications in Node.js and TypeScript (e.g. REST APIs, microservices, gRPC calls, GraphQL APIs, ..., anything that talks to a database). The main tool Prisma Client is a query builder that's used to programmatically send queries to a database from Node.js/TS. Hasura is a "GraphQL-as-a-Service" provider that generates a GraphQL API for your database. This GraphQL API is typically accessed by frontend developers. That setup can be great when your application doesn't require a lot of business logic and the CRUD capabilities that are exposed in the GraphQL API fit your needs (though I believe you can add business logic in Hasura by integrating serverless functions). With Prisma, you're still in full control of your own backend application and can choose whatever tech stack you like for developing it (as long as it's Node.js-based, though Prisma Client will be in available in more languages the future)! By the way, we also love GraphQL. We're currently brewing a new "GraphQL application framework" that can be used on top of Prisma. That way it will be possible to auto-generate resolvers for Prisma models to reduce the boilerplate you need to write, while still keeping the full control of your GraphQL schema. You can learn more about this here: https://www.nexusjs.org/#/ https://www.nexusjs.org/#/
- gavinray 7y ago
  I want to point out a defining characteristic between Hasura and Prisma: While Hasura does work to auto-generate a GraphQL API from an existing database, it also has a web console that lets you build your database models and relationships, plus permission logic and authorization point-and-click. Custom business-logic outside of the CRUD it generates is done by writing HTTP endpoints that you can wrap as "Actions", which it generates GraphQL types and resolvers for as part of it's schema. IE, you will want to define an API endpoint for login/signup, and declare these as "Actions", which you can then query from Hasura's schema. An SDK/toolkit can be auto-generated from the GraphQL schema Hasura produces using graphql-code-generator, giving you strongly-typed query/mutation/subscription components in your desired frontend framework (IE React/Vue/Angular + Apollo/urql etc.) Scheduled tasks/cronjob functionality is under development as well. Prisma gives you a "finer grained" set of tools to "build" an application with, where Hasura kind of just hands you the whole thing (though in an opinionated fashion).

rlili 7y ago

Is real-time subscriptions on the roadmap? It's the most killer feature of Hasura and Postgraphile IMO.

nikolasburk 7y ago
Nikolas from Prisma here, a realtime API for Prisma is certainly on our roadmap – as Prisma doesn't provide a GraphQL interface, this most likely will not come in the form of GraphQL subscriptions though but another (programmatic) realtime API. However, using Nexus [1] on top of Prisma, you'll be then be able to turn Prisma's realtime API into GraphQL subscriptions. All of this is quite a bit further down the road, but certainly on our radar and part of future plans! We have an open feature request for that here: https://github.com/prisma/prisma/issues/298 https://github.com/prisma/prisma/issues/298 [1] https://www.nexusjs.org/#/ https://www.nexusjs.org/#/
hleszek 7y ago
You can put an apollo server on top of prisma and then you can do the subscriptions yourself with a pubsub (redis in our case)

ricardobeat 7y ago

Was really excited about this until I got to "smart node module". Isn't changing the contents of a package in node_modules going to break any kind of caching, de-duplicating etc? In my current project we install node_module` ahead of time and bake it into a docker image, it is quite common.

codegladiator 7y ago
Is there any other framework or library using these "smart" node_modules ? I never noticed.
- nikolasburk 7y ago
  I don't believe so, this term was coined by one of our community members and we really liked it and decided to adopt it to distinguish Prisma Client conceptually from "conventional" (for lack of a better term) node modules.
  - eyelidlessness 7y ago
    Was there consideration of using something like schemats[1] and allowing users to specify where they want to store the types for their schema? Storing them in `node_modules` is extremely unidiomatic and probably rules this library out for me even though it's otherwise attractive at first glance. [1]: https://github.com/SweetIQ/schemats https://github.com/SweetIQ/schemats
    - nikolasburk 7y ago
      You can specify where you want to generate Prisma Client yourself, `node_modules` it's just the default. See my response above: > Also note that you can actually generate Prisma Client into a different location [4], so if you prefer not to have it in node_modules, that's totally possible as well. [4] https://www.prisma.io/docs/reference/tools-and-interfaces/prisma-client/generating-prisma-client#specifying-the-target-location-for-prisma-client https://www.prisma.io/docs/reference/tools-and-interfaces/pr...

eitland 7y ago

Edit: please read nikolasburk's answer below which makes a lot of sense. The docs weren't an attempted attack on all ORMs but rather a description of problems with certain Javascript ORMs. My original post: This looked interesting at first but this reads like someone either don't know a thing about JPA and Entity Framework or are deliberately misrepresenting them: > ORMs are libraries that map tables in your database to classes in your programming language. Prisma on the other hand is an auto-generated query builder that exposes queries which are tailored to your models. All Prisma Client queries return plain old JavaScript objects. Yep, tables maps to classes, but guess what gets returned? Plain Old Java (or CLR) Objects. And guess what: Thanks to those languages well thought out design and extensive metaprogramming abilities this can all be done without making up a new language also. This is probably the harshest I've been here on HN, but smearing good solutions really doesn't sit well with me.

nikolasburk 7y ago
Hey, thanks a lot for the feedback (and I've seen harsher words on HN, so no worries)! I wrote most of the docs, so more than happy to take any feedback to see where it can improved! What I'm mostly trying to refer to are ActiveRecord style ORMs in the Node.js ecosystem (such as Sequelize and TypeORM). With those libraries, you often have model objects that can get really complicated to work with, these are not plain objects but implement lots of additional behaviour for storage and retrieval of data, often times business logic as well. Compared to that, working with plain objects (which are statically and structurally typed) is a fundamentally different approach that's hopefully easier to reason (at least that's what I've found from my personal experience).
- eitland 7y ago
  Ok, thanks for replying. I've been busily trying to reword my post since talking down to people who stand up and make things really isn't my thing either. I guess your explanation here makes a lot of sense - I don't know much about Javascript ORMs.
- eropple 7y ago
  I don't really understand the claim you're making here--you have to go out of your way in TypeORM to get ActiveRecord objects instead of plain JavaScript objects. The happy path is pretty firmly in data-mapper territory; as an example, for all the shade I will happily fling NestJS's way they just hand you a Repository and tell you to get on with your day. There's also stuff like Objection.js (which works well in TypeScript), too. I don't dislike Prisma, but the framing is really strange to me.

zaiste 7y ago

Those, who prefer a more old-school approach, may find PgTyped [1] interesting: you write SQL and you have typings in TypeScript. Still very alpha, but promising. I'm working on integrating PgTyped into Huncwot [2] [1]: https://github.com/adelsz/pgtyped https://github.com/adelsz/pgtyped [2]: https://github.com/huncwotjs/huncwot https://github.com/huncwotjs/huncwot

zeroz 7y ago

Looks very interesting. At the moment we're using a Node.js + Postgres + Sequelize ORM [1] + Express setup in production and are very happy. All lot of features and very robust setup. Any production ready experience with Prisma? [1]: https://sequelize.org/v5/ https://sequelize.org/v5/

kemcho 7y ago

I LOVE massivejs[1], a query builder type library for Postgres in nodejs. Is prisma2 like massivejs but for typescript? If someone’s tried both, would love a quick comparison :) [1] https://massivejs.org/ https://massivejs.org/

nikolasburk 7y ago
Massive is great and we certainly took some inspiration from it (in fact we're friends with Dian, the author of Massive and are fans of her works). The level of type-safety when using Prisma Client with TypeScript is indeed a major factor that sets Prisma apart from other DB libraries in general (not Massive in particular). Would also love to hear what other people think of the two in comparison! :)
zeroz 7y ago
That's why I love HN! One published new solution and a whole tree of wonderful comments about related tech.

nojvek 7y ago

The fact that the returned objects are plain old javascript objects (POJOs) that's nice. The smart module bit, it's a bit scary. basically all I want is a lightweight layer that exposes a promise api to deal with different databases in a uniform manner. 1) sync to schema.json (this json file contains info of all tables, their columns, indices and foreign keys). I can sync to db or from db. This lets me have my state of schema committed to git, and easily move from dev -> staging -> prod. Django migrations are a giant pain in the ass. Don't do smart fancy node modules either. 2) autogenerated typescript types, this are nice. But again don't do fancy node modules, have the typescript types committable to git repo. It makes it easy to diff and bisect when things fo awry. 3) Super light weight Object -> sql. Access foreign relationships as promises (always). Make it very easy to debug the generated sql for perf reasons. Django does some bits well but it's insanely slow at times. Doing things with raw sql should be just as fast as using a library.

nikolasburk 7y ago
Prisma Client is generated into node_modules by default (because that's the most familiar thing for JS/TS devs), but you can specify any target location you like for it: https://www.prisma.io/docs/reference/tools-and-interfaces/prisma-client/generating-prisma-client#specifying-the-target-location-for-prisma-client https://www.prisma.io/docs/reference/tools-and-interfaces/pr...
- nojvek 7y ago
  getting a `Not Found`

phiresky 7y ago

This seems to be solving mostly the same problem as the following libraries: [1] https://github.com/phiresky/ts-typed-sql https://github.com/phiresky/ts-typed-sql [2] https://github.com/Ff00ff/mammoth https://github.com/Ff00ff/mammoth [3] https://github.com/AnyhowStep/tsql https://github.com/AnyhowStep/tsql [4] https://github.com/travigd/vulcyn https://github.com/travigd/vulcyn A query in one of those looks like the following: const rows = await select(list.id, list.createdAt) .from(list) .where(list.createdAt.gt(now().minus(`2 days`)).or(list.value.eq(0))) .limit(10); The resulting type of `rows` is inferred by TypeScript to the corresponding correct type (`{id: string, createdAt: Date}`) Prisma solves the problem by generating code, while all of these do it completely in type-level within typescript. Prisma also seems to introduce its own query language, while the above linked libraries stay closer to SQL. [1] was written by a friend of mine and I'm using it in production to great success. I wouldn't recommend it though because it has repeatedly broken with new TypeScript updates since it uses very complex type structures and the dev has basically given up on it due to the complexity. [2] is probably the most production-ready, though it has some design choices I'm not sure about. [3] is the most well-designed, and can handle complex scenarios (including differentiating between join types etc). But it's incomplete so far. [4] I have not used. Pure type-level has the advantage of not adding a compile-step and keeping everything in a tool you already know. But all of the above have the disadvantage that the resulting type structures are very complex - most TS devs would have a hard time understanding the internals of the libraries and the resulting type errors can be unreadable. They can also cause the TS compiler to slow down significantly (in the past [1] had exponential compile time when adding a new column, though this has been fixed). Also, since the TS compiler uses heuristics in multiple places and the type system is not sound, Microsoft has introduced regressions that have broken [1] in every other release.

adsharma 7y ago
This doesn't work well when you have lots of queries that require a self-join. Get me a friend of a friend of a friend who joined 2 days ago. https://github.com/facebookexperimental/fquery/blob/master/tests/test_operators.py https://github.com/facebookexperimental/fquery/blob/master/t...
timmy-turner 7y ago

samblr 7y ago

I was really excited when Prisma1 came out. It would be understatement to mention that Prisma1 was way overpromised and nothing ever materialised. With Prisma2, honestly disappointed as it is too little to show for. This is an ORM like library that supports only couple of databases with database migrations still in experimental state with broken links for workarounds[1] Also Prisma2 has half of the features at 'No / Not yet' supported state - https://www.prisma.io/docs/reference/database-connectors/database-features https://www.prisma.io/docs/reference/database-connectors/dat... Well makes me wonder what's wrong with TypeORM which supports 8 different databases with full feature support and migrations that work! [1] https://www.prisma.io/docs/reference/tools-and-interfaces/prisma-migrate https://www.prisma.io/docs/reference/tools-and-interfaces/pr... Data Validation Cascading delete Cascading update Renaming existing table Renaming existing column

nikolasburk 7y ago
> I was really excited when Prisma1 came out. It would be understatement to mention that Prisma1 was way overpromised and nothing ever materialised. While I can understand your sentiment, I don't think this is quite true! We've seen a number of companies very successfully adopt Prisma 1 – ultimately we realized though that the vision of building a new way for application developers to access their database can't be built on top of the JVM. At that point, we needed to make a tough judgement call and decided to rewrite Prisma in Rust. Needless to say that this was quite a challenge, but our engineers have done an absolutely outstanding job of managing this rewrite. We certainly had a number of tough learnings, especially when it came to the variety of different DB schemas out there that we needed to support with our introspection. I'm really proud of the result though, we've built a strong and stable foundation that allows us to expand the functionality of our tools over time – this would not have been possible without the rewrite! > With Prisma2, honestly disappointed as it is too little to show for. This is an ORM like library that supports only couple of databases with database migrations still in experimental state with broken links for workarounds[1] Please recall that we're just launching into Beta. As I said, we now have the foundation to expand the functionality of our tools! You'll see a lot of exciting improvements and new tools from Prisma over the next few months! Sorry about the broken links, I'm in the process of fixing most of them! In this case, the links point to the "Guides > Database workflows"-section which contains a number of helpful step-by-step tutorials for performing certain schema migrations (e.g. cascading deletes [1]) and using those with Prisma Client. (While these features are not supported by Prisma Migrate yet, you can still configure them in your DB and use Prisma Client for DB access). [1] https://www.prisma.io/docs/guides/database-workflows/cascading-deletes/postgresql https://www.prisma.io/docs/guides/database-workflows/cascadi...

alde 7y ago

This looks great and should surely cover most of the CRUD needs of simpler apps and hopefully even more. On the other hand, in my experience such complicated abstractions eventually leak, especially due to the complicated nature of the relational model and modern SQL. For developers not keen on adding a thick indirection layer between the app and the DB, I have been trying to make raw SQL easier and more reliable to use directly in TS with PgTyped[1]. In general, I think most people are more than glad to use raw SQL solution instead of a mapper as long as it has: 1) Realtime parameter/result type inference in their language of choice. 2) Has autocomplete and validation in their IDE 3) Is composable, allowing to join queries/sub-queries.. So far I have been able to implement SQL-in-TS type inference in PgTyped[1] with autocomplete and validation on the way. [1]: https://github.com/adelsz/pgtyped https://github.com/adelsz/pgtyped

nikolasburk 7y ago
pgtyped looks awesome, fantastic work! We're huge fans of type-safety at Prisma so anything that makes working with DBs type-safe is right down our alley! :D I think one thing that distinguishes Prisma (on the longer run) from a library like pgtyped is that Prisma will enable more database workflows than just database access. With Prisma Migrate, you can alter your DB schema and keep a migration history, Prisma Studio will enable lots of DB workflows on a GUI level, and Prisma Cloud will have great integrations for teams and larger scale organizations eventually. All that being said, because Prisma is a DB toolkit, you can also pick and choose any tools you like from it. Nothing would e.g. speak against using Prisma Migrate to run your schema migrations but keep accessing your DB with pgtyped, in fact I think this would be an awesome combination :)

heymartinadams 7y ago

I’ve been using Prisma in development and highly recommend it. There’s nothing like it out there!

adsharma 7y ago

Why generate types from a query when you can write a schema for your objects and then write queries where types can be inferred based on object types and query constructs? Some ideas from a recently open sourced project: https://github.com/facebookexperimental/fquery/blob/master/tests/test_operators.py https://github.com/facebookexperimental/fquery/blob/master/t...

andy_ppp 7y ago

It's alright isn't it to get something done fast, until this huge amount of code that you will never understand bites you in the ass. I'm secretly rewriting an API written in Prisma 1 into something lower level that actually allows me to write database queries, optimise what is going on, look into the simple underlying abstractions if things go wrong and essentially produce something I can reason about without just hoping nothing goes wrong under the hood. Apollo codegen is what you want if you'd like your Typescript frontend to be consuming the API in a typesafe way.

crubier 7y ago
You might want to have a look at Postgraphile. It is nice

beart 7y ago

I wish I was not stuck on Ms SQL server. The JS ecosystem tends to ignore it or treat it as a second class citizen. Would love to check this out otherwise.

ronlobo 7y ago

Makes sense, non-type-safe language, we can push type safety guarantees to the persistence layer by coupling the domain models to the type-safe data models.

crubier 7y ago

Why on earth did Prisma take the choice to move away from a brilliant automatic GraphQL backend as a service to some kind of weird ORM? Prisma became relevant during their Prisma 1 time, it was one of the first solutions to automatically generate GraphQL endpoints from DB schemas. It only had to keep going this way to lead the whole market. But they chose not too, and competing solutions such as Graphile beats prisma 1 so much now. Meanwhile they have been stuck for 2 years in their new weird direction of Prisma 2, with no results to show for, and no clear vision. The GraphQL server is gone, even though it was central to their product. Who cares about yet another ORM? I can generate types from any GraphQL endpoint automatically anyway!

timmy-turner 7y ago

Not getting warm with any query/ORM library out there. My own take of interfacing with an SQL database with Typescript: a query generator that uses mapped types a lot to infer result set types from queries and a schema file. https://github.com/hoeck/typesafe-query-builder https://github.com/hoeck/typesafe-query-builder Not sure if thats a good idea and if the Typescript inference even scales that well when using lots of tables. Any feedback and criticism would be welcome.