Add builder pattern for Config by LonerDan · Pull Request #366 · tiberius-rs/tiberius

LonerDan · 2024-10-29T12:20:34Z

Changes the way Config is constructed by introducing helper struct ConfigBuilder, which follows the builder pattern. This enables more ergonomic function call chaining, while still preserving the option to call them one by one as previously.

Based on this and this, the variant consuming and producing mutable references was chosen, since it allows both ergonomic function call chaining and manually calling individual functions, which is required in case of values set conditionally.
As a side effect, this also allows constructing multiple Configs from the same builder.

Changes the way `Config` is contructed by introducing helper struct `ConfigBuilder`, which follows the builder pattern. This enables more ergonomic function call chaining, while still preserving the option to call them one by one as previously.

Mirrors the idea of tiberius-rs/tiberius#366, but not its diff: as tasks.md flagged, the upstream PR outright deleted `Config::new()` and every one of its setters, replacing them with a builder-only API - a breaking change for essentially every existing caller (including this fork's own docs, examples, and every test in the suite). Reimplemented from scratch as a pure addition instead: `Config::new()` and all of its setters are completely untouched. `Config::builder()` returns a new `ConfigBuilder` wrapping a `Config`, with one chainable (`&mut Self`-returning) method per existing setter - covering every setter this fork now has, including the ones added this session that didn't exist when #366 was opened (`client_name`, `host_name_in_certificate`, `send_string_parameters_as_unicode`, `multi_subnet_failover`, `packet_size`). Each builder method just calls straight through to the corresponding `Config` method, so there is exactly one implementation of each setting's logic. `packet_size` is the one fallible setter (range-validated, added this session in #400) - its builder method returns `crate::Result<&mut Self>` instead of `&mut Self`, so chaining continues normally with `?` on success. `build(&self)` clones the wrapped `Config` rather than consuming the builder, so a builder can be reused as a shared base for producing several slightly different `Config`s (matching the shape of the original PR's `build`, which was worth keeping even though the rest of that PR wasn't). Added unit tests confirming: `Config::new()` and its direct setters still compile and work unmodified, the builder produces a `Config` equivalent to the direct-setter path for the same values, the builder remains usable after `build()`, and `packet_size`'s validation/chaining behavior. Verified: - cargo check: default, --features=rustls, --features=vendored-openssl, --no-default-features - cargo clippy --all-targets -- -D warnings, for default and rustls - cargo fmt --check - cargo test --lib (181 passed) - cargo test --doc against a live server (28 passed, including the new ConfigBuilder doctest) - Live integration tests over rustls: 305 passed (102 bulk + 203 query), unaffected since this is purely additive Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0156Di1tRRLsJK8ctU1AmAJr

@LonerDan