-
-
Notifications
You must be signed in to change notification settings - Fork 138
[Feature Request] Support query batching (prisma fluent api) #2535
Description
Is your feature request related to a problem? Please describe.
When using any orm for a graphql server, there is a common n+1 problem. E.g. consider this query which fetches all users with their posts:
query {
users {
username
posts {
name
}
}
}The way a common graphql server resolves this is by first fetching all users and then for each executing a query to fetch his posts, the calls to the zenstack orm are equivalent to:
db.user.findMany();
db.post.findMany({ where: { user_id: 1 } });
db.post.findMany({ where: { user_id: 2 } });
db.post.findMany({ where: { user_id: 3 } });Which corresponds to roughly these sql queries (n+1 queries):
SELECT * FROM users; -- user ids: 1, 2, 3
SELECT * FROM posts WHERE user_id = 1;
SELECT * FROM posts WHERE user_id = 2;
SELECT * FROM posts WHERE user_id = 3;In prisma there is an integrated dataloader which automatically batches similar queries in the same js tick, so it results in the following (2 queries) when using the fluent API:
db.user.findMany();
db.user.findUnique({ where: { id: 1 } }).posts();
db.user.findUnique({ where: { id: 2 } }).posts();
db.user.findUnique({ where: { id: 3 } }).posts();SELECT * FROM users; -- user ids: 1, 2, 3
SELECT * FROM posts WHERE user_id IN (1, 2, 3);For that there is the fluent API, which is (per discussion on discord) not ported with the kysely rewrite.
Describe the solution you'd like
The way prisma does it may not be that intuitive and I do not see a reason why only findUnique calls get used for batching. So it would be a great addition if zenstack could support batching and also of more than findUnique calls when they have parameters in common.
Describe alternatives you've considered
Using a custom dataloader implementation ontop of zenstack orm
Additional context
/