Add UseMySqlConnector overload for MS DI database configuration

UsePersistentStore enables implementation-specific extension methods, such as UseMySql. These dictate both the dialect and the specific database provider used. We can do better.

As a rule, we should depend on abstractions, not specific third-party packages. The developer should choose the concrete database provider. All that Quartz needs is a way to produce a DbConnection on demand.

Concretely, the issue I am running into is a code base that uses the truly async MySqlConnector (for good reasons), with Quartz’s MySQL implementation being tightly coupled to MySql.Data. This results in the need for two different MySQL connectors in one application. Additional complications arise, such as one connector needing UseXaTransactions=False to exhibit the desired behavior, but the other rejecting that option, defaulting to that behavior instead.

Scope

Although I am requesting this feature primarily for the MySql implementation, it would make sense to have for all the ADO.NET-based implementations.

Proposed Solution

Next to SchedulerBuilder.AdoProviderOptions.ConnectionString, we could introduce SchedulerBuilder.AdoProviderOptions.ConnectionFactory. A Func<DbConnection> type would do nicely.

If only ConnectionString is set, we maintain the existing behavior. If only ConnectionFactory is set, we use that to provide connections, and these are expected to come with their connection strings preassigned.

If both properties are set, then the connection factory is used to produce a DbConnection, and then the connection string is used to assign DbConnection.ConnectionString. Although this may seem unimportant, it provides a sensible way of handling the presence of both properties, and it fulfills a niche use case where the developer wants to separately provide DbConnection instantiation vs. ConnectionString selection.

Alternative Solution

An alternative solution might be to specify the assembly name, namespace, and type name of the concrete DbConnection type to use. We would rely on it having a default constructor. However, I consider this solution inferior. Not only are the strings obscure and error-prone, but they lack the Func<DbConnection>'s ability to configure the DbConnection in different ways, should the developer so desire.

[Timovzl]

There’s already IDbProvider.

@lahma Good point. That works.

[lahma]

There’s already IDbProvider. Which you can use to create connections etc. I think there’s no need to add yet another abstraction?