Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
[db-queries] Decouples CTE usage from Diesel (RegionAllocation) (#5063)
Diesel's complex type have been a pain point in the region allocation CTE in particular: - It relies on several JOINs, which requires explicitly adding Diesel macros to make the type system happy - With ongoing work by @jmpesp , it would require additional `alias!` calls to allow a table to appear in a `SELECT` clause in multiple spots - Generally, the disconnect between "what SQL do I want to write" and "what invocations will make Diesel happy" has been "not really worth it" in this space. This PR does the following: - It relies heavily on https://docs.diesel.rs/master/diesel/query_builder/struct.SqlQuery.html , which is Diesel's "you do whatever you want" query type. Although this is still using Diesel, this usage is actually pretty aligned with other simpler DB interfaces - other crates (see: [tokio_postgres](https://docs.rs/tokio-postgres/latest/tokio_postgres/struct.Client.html#method.query)) take arguments like "a String + list of bind parameters", in some form. - It adds support in `raw_query_builder.rs` for a wrapper around Diesel's `SqlQuery` object, to make SQL injections less possible and to track bind parameter counting. - It fully converts the `RegionAllocation` CTE to use this builder, interleaved with raw SQL. - Since a large portion of the CTE was rote "repeated columns", I also added a function, accessible as `AllColumnsOf<Table>::with_prefix(&'static str)`, to enumerate all the columns of a table as strings. - I also added a simple `EXPLAIN` test to the CTE, to quickly validate that CockroachDB thinks it's producing valid output. Here are my thoughts for future improvements: - [ ] I spent a while trying to make the "query construction" a compile-time operation. I think that this is possible with nightly features. I think this is extremely difficult with stable rust. However, I think this is a great direction for future work, as statically-known queries would be easier to cache and validate. - [ ] I'd like to encapsulate more type information about the constructed query, as an "input/output" object. Right now, we're relying on existing integration tests for validation, but it seems possible to send these "example" queries (like the ones I'm using in my `EXPLAIN` tests) to ask CockroachDB to validate type information for us. - [ ] I want to make this format as digestible as possible. If there's anything I can do to make this easier to read, write, and validate, I'm totally on-board. I have been debating adding macro support for SQL formatting the raw strings, but I'm on the fence about whether or not that would make interleaved code harder to parse by humans. - As a follow-up: I'm auto-formatting the output of these queries in the EXPECTORATE-d output files
- Loading branch information