SqlServerCache: exposing sql connection factory
- Dominant language
- C#
- Stars
- 38.4k
- Forks
- 10.9k
- Avg merge
- 2d 6h
- Merged PRs (30d)
- 290
Description
### Background and motivation
In containerised environments running without a Kerberos sidecar, `Microsoft.Data.SqlClient` requires `SspiContextProvider` to be set on the
`SqlConnection` instance before it is opened. `SqlServerCache` currently creates connections internally via `new SqlConnection(connectionString)` with no extension point to intercept or configure that instance.
This is a general issue with current configuration options, as other SqlConnection properties (for example `RetryLogicProvider`, `Disposed` event handler) are also not exposed.
This causes issues (or a need to reimplement whole SqlServerCache) if you want to control those things.
### API Proposal
I suggest adding the connection factory to options directly, this way there is no breaking change.
### API Usage
```csharp
services.AddDistributedSqlServerCache(_ => { });
services.AddOptions()
.Configure((options, tokenService) =>
{
options.SchemaName = "dbo";
options.TableName = "Cache";
options.ConnectionFactory = () =>
{
var conn = new SqlConnection("Server=fake");
conn.AccessToken = tokenService.GetToken();
return conn;
};
});
```
### Alternative Designs
Alternatively, you could update `SqlServerCacheOptions` to have all of the properties that are contained on SqlConnection. That does not seem desirable though.
Another approach altogether would be to separate CacheOptions from connectivity concerns, essentially adding something like:
```
public static IServiceCollection AddDistributedSqlServerCache(this IServiceCollection services, Action setupAction, Func connectionFactory)
{
}
```
### Risks
If design without breaking changes is selected - none?
Contributor guide
Assessment
This issue has not been assessed yet.