4 ms·
I don't think it's talking about returning a database per se. Their contribution seems to be a new type of query that, instead of using joins to join together r
by shrimpx 3y ago
I don't think it's talking about returning a database per se. Their contribution seems to be a new type of query that, instead of using joins to join together results from many tables into a single denormalized output "table," it actually returns multiple output "tables" whose rows you can associate together in your code. It's kind of a "normalized join," if you will.
- leblancfg 3y agoYeah. 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.