|
| 1 | +# Usage of `macros.preferred-crates` in `sqlx.toml` |
| 2 | + |
| 3 | +## The Problem |
| 4 | + |
| 5 | +SQLx has many optional features that enable integrations for external crates to map from/to SQL types. |
| 6 | + |
| 7 | +In some cases, more than one optional feature applies to the same set of types: |
| 8 | + |
| 9 | +* The `chrono` and `time` features enable mapping SQL date/time types to those in these crates. |
| 10 | +* Similarly, `bigdecimal` and `rust_decimal` enable mapping for the SQL `NUMERIC` type. |
| 11 | + |
| 12 | +Throughout its existence, the `query!()` family of macros has inferred which crate to use based on which optional |
| 13 | +feature was enabled. If multiple features are enabled, one takes precedent over the other: `time` over `chrono`, |
| 14 | +`rust_decimal` over `bigdecimal`, etc. The ordering is purely the result of historical happenstance and |
| 15 | +does not indicate any specific preference for one crate over another. They each have their tradeoffs. |
| 16 | + |
| 17 | +This works fine when only one crate in the dependency graph depends on SQLx, but can break down if another crate |
| 18 | +in the dependency graph also depends on SQLx. Because of Cargo's [feature unification], any features enabled |
| 19 | +by this other crate are also forced on for all other crates that depend on the same version of SQLx in the same project. |
| 20 | + |
| 21 | +This is intentional design on Cargo's part; features are meant to be purely additive, so it can build each transitive |
| 22 | +dependency just once no matter how many crates depend on it. Otherwise, this could result in combinatorial explosion. |
| 23 | + |
| 24 | +Unfortunately for us, this means that if your project depends on SQLx and enables the `chrono` feature, but also depends |
| 25 | +on another crate that enables the `time` feature, the `query!()` macros will end up thinking that _you_ want to use |
| 26 | +the `time` crate, because they don't know any better. |
| 27 | + |
| 28 | +Fixing this has historically required patching the dependency, which is annoying to maintain long-term. |
| 29 | + |
| 30 | +[feature unification]: https://doc.rust-lang.org/cargo/reference/features.html#feature-unification |
| 31 | + |
| 32 | +## The Solution |
| 33 | + |
| 34 | +However, as of 0.9.0, SQLx has gained the ability to configure the macros through the use of a `sqlx.toml` file. |
| 35 | + |
| 36 | +This includes the ability to tell the macros which crate you prefer, overriding the inference. |
| 37 | + |
| 38 | +See the [`sqlx.toml`](./sqlx.toml) file in this directory for details. |
| 39 | + |
| 40 | +A full reference `sqlx.toml` is also available as `sqlx-core/src/config/reference.toml`. |
| 41 | + |
| 42 | +## This Example |
| 43 | + |
| 44 | +This example exists both to showcase the macro configuration and also serve as a test for the functionality. |
| 45 | + |
| 46 | +It consists of three crates: |
| 47 | + |
| 48 | +* The root crate, which depends on SQLx and enables the `chrono` and `bigdecimal` features, |
| 49 | +* `uses-rust-decimal`, a dependency which also depends on SQLx and enables the `rust_decimal` feature, |
| 50 | +* and `uses-time`, a dependency which also depends on SQLx and enables the `time` feature. |
| 51 | + * This serves as a stand-in for `tower-sessions-sqlx-store`, which is [one of the culprits for this issue](https://github.com/launchbadge/sqlx/issues/3412#issuecomment-2277377597). |
| 52 | + |
| 53 | +Given that both dependencies enable features with higher precedence, they would historically have interfered |
| 54 | +with the usage in the root crate. (Pretend that they're published to crates.io and cannot be easily changed.) |
| 55 | +However, because the root crate uses a `sqlx.toml`, the macros know exactly which crates it wants to use and everyone's happy. |
0 commit comments