Namespace ProtoTest.Sql

ProtoSqlSession: The per-test database session: the connection ProtoTest owns, the transaction every access technology must enlist in when the isolation strategy needs one, and the lifecycle that opens, starts and releases both. One type owns the transaction, so no hook can leave one half-started.

SqlAddressKeys: The code-declared configuration keys that can provide the SQL connection: sql => sql.AddressKeys.Add("ConnectionStrings:Orders"). The set is a code API, not a bound option: the capability decision is made when the host is built, before options bind, so a key that only configuration knows cannot promise a connection the build already decided against.

SqlAddressRule: The SQL address rule: whether the run can provide a connection for the keys AddressKeys declares, and the failure the accessors raise when it cannot. The same predicate decides the Store capability at Build: a key counts as provided when it has a configured value, or a registered infrastructure piece declares it and fills it when it starts. A sibling access technology - Entity Framework Core, Dapper, raw ADO.NET - shares the rule: read DeclaredKeys(IServiceCollection) while the host builds to gate its own Store capability, and use IsInert(ProtoExecutionContext, SqlOptions) or ThrowIfInert(ProtoExecutionContext, SqlOptions) on the same keys at use time, so the capability decision and the failure text cannot disagree with AddSql.

SqlHookOrders: The hook orders ProtoTest.Sql composes its setup from. Setup hooks run in ascending order, so the connection hook runs first and the Entity Framework Core enlistment hook after it; the numbers live here rather than in each hook so the coupling is stated once.

SqlOptions: Configures how ProtoTest owns and isolates a database connection during a test.