5 ms·

I'm completely perplexed at some of the functionality that's absent in Prisma? I'm coming from the Rails/Django world for reference. Can anyone help me understa

I'm completely perplexed at some of the functionality that's absent in Prisma? I'm coming from the Rails/Django world for reference. Can anyone help me understand if I'm out in left field or does this technology only cover basic use cases? - No supported way to do a case-insensitive sorting. https://github.com/prisma/prisma/issues/5068 - Can’t sort by an aggregate value like user’s post count. https://github.com/prisma/prisma/issues/3821 - Can’t control between inner/left join. - Can’t do subqueries. - Migration rollbacks are experimental maybe unsupported now? At least I only see mention in Github issues and not in the docs. - Transactions appear to expect a series of queries? It doesn’t look like you can execute any app code during a transaction? - No support for pessimistic row locking e.g. SELECT… FOR UPDATE ? - No way to mixin raw query partials like `where('name ILIKE ?')`. You either need to write the whole query raw or not. - Validations are done at the database level. - Complex validations seem tricky to write in this format - No built-in way to make clean user-facing validation messages. - You can’t check that a model instance is valid without just trying to insert it into the database - The official documented validation example has you connecting via psql and adding a constraint? - So following the offical example my validations aren’t documented in the codebase via a model or a migration? - Also they don’t have a validation example documented if you’re using MySQL instead of Postgres? - Cascading deletes are handled the same way as validations. As in Prisma basically does nothing other than document how to implement it yourself outside of the library. - No model methods. I guess that's not a surprised because it's "not an ORM". A model really is just a data mapping? Anyways it seems like you would end up rolling your own wrapper around this and there's no recommendations on standardized architecture. - No callbacks. These have been controversial at times so are teams using Prisma writing something akin to "services" instead? - Syntax nitpick but one of these is vulnerable to a SQL injection and it seems really easy for a new developer to get mixed up? - prisma.$queryRaw(`SELECT \* FROM User WHERE email = ${email}`); - prisma.$queryRaw`SELECT \* FROM User WHERE email = ${email}`; - No way of batch loading like Active Records’s find_in_batches / find_each. All objects are just loaded into memory? - No way of hooking into queries for instrumentation. e.g. ActiveSupport::Notifications.subscribe FYI - This is after fairly brief research. Not guaranteed 100% accurate.

abaldwin99 5y ago
@nikolasburk can you comment? Before compiling this list I was seriously considering using Prisma to kick off a big upcoming project. In the spirit of being open-minded I'd really like to know if I'm fundamentally misunderstanding Prisma capabilities.
- nikolasburk 5y ago
  This is a pretty extensive list! Are all of these points are full blockers for you or are there individual points that you care more about while others might be rather "nice to have"? If most of them are real blockers, you probably shouldn't use Prisma [1], and that's ok :) Prisma certainly is not perfect and whether you should use it depends on your project and individual requirements. What I can tell you is that we are shipping releases [2] with new features and improvements every two weeks. We are also very eager to learn about more use cases that people want to accomplish with Prisma. The best way to bring these to our attention is by commenting on existing GitHub issues and creating new ones if the one for your use case doesn't exist yet. This helps us prioritze and implement these new features. We also have a roadmap [3] where you can see all the features that we are currently working on. Hope that helps for now! [1] https://www.prisma.io/docs/concepts/overview/should-you-use-prisma https://www.prisma.io/docs/concepts/overview/should-you-use-... [2] https://github.com/prisma/prisma/releases https://github.com/prisma/prisma/releases [3] http://pris.ly/roadmap http://pris.ly/roadmap
  - abaldwin99 5y ago
    Thanks for getting back to me! Most of these are pretty important to us. I did try to put lower priority items near the bottom of the list. However, I did omit several nice-to-haves already. e.g. ActiveRecord's ability to diff changes after an update (ActiveModel::Dirty) I wouldn't say any of them are complete full blockers by themselves but cumulatively yes they prevent us from considering Prisma for most projects.
tomhoule 5y ago
I can clarify one point, relative to migration rollbacks. We indeed chose not to implement down migrations as they are in most other migration tools. Down migrations are useful in two scenarios: in development, when you are iterating on a migration or switching branches, and when deploying, when something goes wrong. - In development, we think we already have a better solution. Migrate will tell you when there is a discrepancy between your migrations and the actual schema of your dev database, and offer to resolve it for you. - In production, currently, we will diagnose the problem for you. But indeed, rollbacks are manual: you use `migrate resolve` to mark the migration as rolled back or forward, but the action of rolling back is manual. So I would say it _is_ supported, not just as convenient and automated as the rest of the workflows. Down migrations are somewhat rare in real production scenarios, and we are looking into better ways to help users recover from failed migrations.

abaldwin99 5y ago

@nikolasburk can you comment? Before compiling this list I was seriously considering using Prisma to kick off a big upcoming project. In the spirit of being open-minded I'd really like to know if I'm fundamentally misunderstanding Prisma capabilities.

nikolasburk 5y ago
This is a pretty extensive list! Are all of these points are full blockers for you or are there individual points that you care more about while others might be rather "nice to have"? If most of them are real blockers, you probably shouldn't use Prisma [1], and that's ok :) Prisma certainly is not perfect and whether you should use it depends on your project and individual requirements. What I can tell you is that we are shipping releases [2] with new features and improvements every two weeks. We are also very eager to learn about more use cases that people want to accomplish with Prisma. The best way to bring these to our attention is by commenting on existing GitHub issues and creating new ones if the one for your use case doesn't exist yet. This helps us prioritze and implement these new features. We also have a roadmap [3] where you can see all the features that we are currently working on. Hope that helps for now! [1] https://www.prisma.io/docs/concepts/overview/should-you-use-prisma https://www.prisma.io/docs/concepts/overview/should-you-use-... [2] https://github.com/prisma/prisma/releases https://github.com/prisma/prisma/releases [3] http://pris.ly/roadmap http://pris.ly/roadmap
- abaldwin99 5y ago
  Thanks for getting back to me! Most of these are pretty important to us. I did try to put lower priority items near the bottom of the list. However, I did omit several nice-to-haves already. e.g. ActiveRecord's ability to diff changes after an update (ActiveModel::Dirty) I wouldn't say any of them are complete full blockers by themselves but cumulatively yes they prevent us from considering Prisma for most projects.

tomhoule 5y ago

I can clarify one point, relative to migration rollbacks. We indeed chose not to implement down migrations as they are in most other migration tools. Down migrations are useful in two scenarios: in development, when you are iterating on a migration or switching branches, and when deploying, when something goes wrong. - In development, we think we already have a better solution. Migrate will tell you when there is a discrepancy between your migrations and the actual schema of your dev database, and offer to resolve it for you. - In production, currently, we will diagnose the problem for you. But indeed, rollbacks are manual: you use `migrate resolve` to mark the migration as rolled back or forward, but the action of rolling back is manual. So I would say it _is_ supported, not just as convenient and automated as the rest of the workflows. Down migrations are somewhat rare in real production scenarios, and we are looking into better ways to help users recover from failed migrations.