4 ms·

I’ve tried Prisma over the last few months, but eventually decided against adopting it in our product because it seems very inflexible when working with many-to

I’ve tried Prisma over the last few months, but eventually decided against adopting it in our product because it seems very inflexible when working with many-to-many relationships. In particular, filtering on foreign keys doesn’t seem possible and requires SQL table joins, which (in our case) has an immensely negative performance impact. Also, the query chaining API doesn’t lend itself well to filtering on multiple relationships. Apart from that, the idea seems really cool and I’m sure the project has a great future ahead of it!

Aeolun 8y ago
Forgive me if I’m missing something here, but joins seem pretty much the only way to do performant foreign key filtering to me. Is this not what you were talking about?
- kilburn 7y ago
  It wasn't my question, but I would assume the caveat they were complaining about is that prisma forced them to perform the join when filtering the original table by just the foreign key (think select * from books where author_id = ? ... no join to aauthors needed here, but some ORMs do that join anyways)
lf-non 8y ago
People facing similar issues might want to try out GRelDAL [1] (disclaimer: I am the author), a simple node.js library for bridging relational databases to graphql APIs. It supports various strategies for loading associations, including joins and bulk sideloading (pre-edge when you know what to fetch before parent entities have been loaded, and post-edge when you need parent entities before). It is still somewhat early stage and the scope is much narrower but it provides a great deal of control to the host application on how the operations are mapped from the graphql layer to the persistence layer. [1] https://gql-dal.github.io/greldal/ https://gql-dal.github.io/greldal/
mavilein 7y ago
Thanks for that honest feedback! That was indeed a drawback we had and we often had this point coming up in customer conversations. This is why we started an effort to lift this limitation a few months ago. The result of this work is a new Datamodel specification that allows you to take full control of how relations are implemented. You can check it out here: [GitHub - prisma/datamodel-v1.1-feedback](https://github.com/prisma/datamodel-v1.1-feedback https://github.com/prisma/datamodel-v1.1-feedback) Your use case description sounds like you want to take really control of a lot of details here. Therefore I would suggest you to introduce a model that is backed by your relation table. Then you can freely filter on this model and then traverse relationships from there. If you want to chat more about how to implement in detail feel free to reach out on our public Slack (my nick there is: marcus).

Aeolun 8y ago

Forgive me if I’m missing something here, but joins seem pretty much the only way to do performant foreign key filtering to me. Is this not what you were talking about?

kilburn 7y ago
It wasn't my question, but I would assume the caveat they were complaining about is that prisma forced them to perform the join when filtering the original table by just the foreign key (think select * from books where author_id = ? ... no join to aauthors needed here, but some ORMs do that join anyways)

lf-non 8y ago

People facing similar issues might want to try out GRelDAL [1] (disclaimer: I am the author), a simple node.js library for bridging relational databases to graphql APIs. It supports various strategies for loading associations, including joins and bulk sideloading (pre-edge when you know what to fetch before parent entities have been loaded, and post-edge when you need parent entities before). It is still somewhat early stage and the scope is much narrower but it provides a great deal of control to the host application on how the operations are mapped from the graphql layer to the persistence layer. [1] https://gql-dal.github.io/greldal/ https://gql-dal.github.io/greldal/

mavilein 7y ago

Thanks for that honest feedback! That was indeed a drawback we had and we often had this point coming up in customer conversations. This is why we started an effort to lift this limitation a few months ago. The result of this work is a new Datamodel specification that allows you to take full control of how relations are implemented. You can check it out here: [GitHub - prisma/datamodel-v1.1-feedback](https://github.com/prisma/datamodel-v1.1-feedback https://github.com/prisma/datamodel-v1.1-feedback) Your use case description sounds like you want to take really control of a lot of details here. Therefore I would suggest you to introduce a model that is backed by your relation table. Then you can freely filter on this model and then traverse relationships from there. If you want to chat more about how to implement in detail feel free to reach out on our public Slack (my nick there is: marcus).