7 ms·
Nice, and I understand why using `getAuthorNames` solves the N+1 here. But... isn't this solving the problem by removing most of what makes it an issue in the
by quibono 22d ago
Nice, and I understand why using `getAuthorNames` solves the N+1 here.
But... isn't this solving the problem by removing most of what makes it an issue in the first place? I imagine most people use ORMs for the SQL <-> native class data sync capability. And this assumes one would run the Acadia query instead.
FWIW I'm not trying to be negative, it's just my general impression is that these N+1 usually occur because people _want_ direct object access and _want_ to write loops, and _want_ to access fields and have the underlying SQL be sorted by the ORM.
- cnity 22d agoThis is my experience too. The solution is to train people to stop wanting to solve data query problems in the application layer.
- lobofta 22d agoAs far as I understand Acadia gives you Acadia <-> Native class data sync, only just Haskell and Elm at the moment unfortunately. I'd be willing to rewrite queries in some other language that transpiles to SQL if it allows me to do all the queries I want and gives me full compile time type support for db access in return. The policies look interesting too by the way, but they don't solve a major IMO.
- ryanrasti 22d ago> I'd be willing to rewrite queries in some other language that transpiles to SQL if it allows me to do all the queries I want and gives me full compile time type support for db access in return. Full typed coverage for db is what I'm doing in Typegres [1] -- including all dialect built-in functions/operators. And regarding policy, instead of RLS it's all based on ocap: reachability is permission. So: `api.user.posts()` automatically injects a `where` clause on the `users` table and it's composable wherever a SQL set expression is allowed: `api.user.posts().join(...).groupBy(...)`. Since we're building up a SQL expression tree, we avoid the N+1 problem entirely. [1] https://typegres.com/ https://typegres.com/
- hobofan 22d agoYes, this does essentially nothing to solve the 1+N query problem. If your solution was to to stuff everything into one query, this was already possible with SQL!