Hello guys. I have a project using ObjectionJS and...
# orm-help
s
Hello guys. I have a project using ObjectionJS and I would like to move it over to Prisma. Do you know of any guide or tutorial which I can use to migrate the ORM ?
j
cc @nikolasburk
Unfortunately not away Sajal - but Objection is using Knex behind the scenes afaik, so you might also have success googling for "Prisma Knex". Let me know if you find any good resources.
s
I want to remove Knex as well and completely move to Prisma. My project is at a starting point where I can afford to make such a big change.
j
Yeah exactly, as ObjectionJS is really Knex, looking for migration guides or articles from Knex to Prisma might also help you.
n
Hey Sajal 👋 while we don’t have a concrete migration guide for migrating from Objection to Prisma yet, you can still look at the existing guides for inspiration, e.g. the one for TypeORM. In fact, the steps are largely the same no matter from where you’re migrating to Prisma: 1. Install and init Prisma 2. Introspect your DB 3. Install Prisma Client 4. Replace your current queries with Prisma Client queries Hope this helps!
👍 2
s
We had a discussion with the architecture team here at my company, they say that Prisma does not support join queries. For that, Prisma runs a select statement and then another statement to fetch data from the related table, is that true ?
j
That depends on the query. Sometimes that is true, as there mostly is no performance impact and it allows additional functionality. Is that a problem?
n
Prisma is indeed joining data in the Rust-based query engine rather than on a DB-level 👍 The main reason for this is that depending on the data set, the execution of JOINs inside of the DB would be more costly than joining it in memory as we do. This is especially true for larger data sets in most real world apps. And for smaller datasets the actual performance degradation can usually be entirely neglected because even though the queries might not be fully optimized, there will be virtually no impact on the perceived performance by the user. That’s the tradeoff based on which we’ve implemented the current querying strategy. While we are planning to make the query execution more flexible in the future to also give developers more options for deciding on a query plan, this approach has been working really well since we released Prisma for production and we’ve rarely seen any actual performance complaints (and if someone is actually running into performance issues with Prisma, we’re quite fast to react on GitHub and resolve the performance issues). There’s a GitHub issue about this here with an interesting discussion going on where you can read more about this. There’s also a nice chapter about “Query Performance Optimization” by O’Reilly.
👍 3