3 ms·
Yeah. I'm imagining e.g. a full database schema at my disposal in the ORM layer, but with only the handful of rows relevant to the logged-in user. Could be use
by leblancfg 3y ago
Yeah. I'm imagining e.g. a full database schema at my disposal in the ORM layer, but with only the handful of rows relevant to the logged-in user.
Could be useful in many read-heavy scenarios, and would make a default way that skips DB fetches.
- shrimpx 3y agoThat’s kind of cool. Also related to local-first, maybe.
- crooked-v 3y agoOne thing to note is that with a row-level security implementation like Postgres you can pretty much do this already. For example, if you have a table `users` with appropriate RLS policies, `SELECT * FROM users` will only return the rows that whoever's doing the selecting is allowed to see.
- leblancfg 3y agoAFAICT that’s limited to single table calls though. I guess you could use to recreate the DB at the ORM level since you know the schema as well. But I still like this idea living at the database layer and not an extra layer of abstraction on top of it.
- PeterisP 3y agoThat is a valid use case, but IMHO the proper mental model for it would be not "SQL statement that returns a database" but rather "a synced partial mirror database instance", i.e. you have a local database server (likely in-memory SQLite or something) that gets synced with the master DB (perhaps even both ways) but only for a specific subset of rows.