|
|
|
|
|
|
by gkapur
1459 days ago
|
|
|
Just curious -- what are the performance trade-offs here? I assume you are basically querying each individual database and then doing a series of joins by doing additional queries? Or are you doing something more sophisticated with cache-ing, etc.? |
|
|
With the SDK, it's just an API contract -- you are saying "I have a web service that implements these endpoints you can call to ask for schema/metadata info + perform a query".
Whatever business logic happens inside of the connector service is opaque, so it's up to the author to implement.
For Hasura's own DB-to-DB joins, we do what's called a "Data-shipment Join". It's similar to what you mention.
DB's are queried in relationship top-down order, and join column values (this is over-simplifying) materialized as a sort of a temp-table in the target DB, which is used to JOIN, down the chain.
It's O(n) where n = (number of DBs in the query), which is best-case given the nature of the problem.
For single-DB joins, we compile these to single aggregated queries using JSON_ARRAY_AGG and JSON_BUILD_OBJECT equivalents in the target dialect.