11–20 of 40 posts
Earlier quoted context omitted.
I hope it is implemented with multiple result sets and a single roundtrip
For sure it is
Earlier quoted context omitted.
If you join multiple/many tables, you could end up with a large volume of data. And yes, this is bit-for-bit duplication—on the network. The query result is (typically) a single table. This table will get serialized as-is, with all duplicate data.
Couldn't we make references as `byte offsets in the result set` work to handle duplication? Real memory pointers wouldn't work over the network of course, but if the database driver would return results like this, the client could easily stitch these together. My hunch is that even if we implement references on a higher level than raw byte offsets it would still be more performant than just returning R1*R2 bytes for…
One could envision a "Cartesian product" operation in the wire protocol, but I'm not convinced that's a good approach.
Earlier quoted context omitted.
Assume you fetch a single customer entity with their 100 order entities as includes. With single query this will join both tables and produce 100 rows that contain the order data but also each one contains the customer data redundantly. Now Imagine you had two includes there, that will multiply the number of rows again. AsSingleQuery is as dangerous as this makes it sound. This works surprisingly well if you know tha…
Databases are incredibly smart when it comes to fetching related data, a single select is indeed better than splitting queries and doing multiple roundtrips. The problem however is in how results are returned over the wire . Duplicating rows is needless, but seems to be still the standard.
I wish EF Core had first-class support for raw SQL, like Dapper.
Alternative query languages like EdgeQL show what first class support for nested data (and navigations) could look like, while the data model is still relational.
What EF needs is support for using postgresql's `array_agg` when `Include`ing collections.