faithlife / faithlifedata

Helpers for querying ADO.NET-compatible databases.

Faithlife.Data

Helpers for querying ADO.NET-compatible databases.

Documentation | Release Notes | Contributing

faithlifedata's Issues

Support command timeout

We should support a WithTimeout Timeout method on DbConnectorCommand that takes a non-zero TimeSpan (or TimeSpan.InfiniteTimeSpan) and returns a new DbConnectorCommand that sets CommandTimeout to the number of seconds (rounding up) when creating the IDbCommand.

A WithNoTimeout method with no parameters could set CommandTimeout to zero (no limit).

Customize parameter name used by DTO properties

DbParameters.FromDto(string name, object dto) could add a prefix to the DTO properties, i.e. {name}_{propertyName}.

Perhaps Func<string, string> name in an overload for full customization, e.g. prop => $"widget_{prop}".

Support Sql.DtoParamNames(Where)

This is similar to Sql.ColumnNames(Where), but generates parameter names for the specified type of DTO, for use with DtoParameters.AddDto, etc.

So Sql.DtoParamNames<WidgetRecord>() generates @WidgetId, @Name, @Weight, i.e. one parameter name for each property.

Support closing lazy-open connections temporarily

Normally the connection is closed when the disposable returned by OpenConnection is disposed, or, in the case of AutoOpen, when the connector itself is disposed. CloseConnection(Async) would allow the connection to be closed earlier than normal.

In the case of AutoOpen, we should reopen the connection immediately, which makes this not very useful, unless LazyOpen is also in use, in which case it won't open until (and unless) it is used again. This is probably the best use case of the new method, but it might also make the code confusing when the connection is used again later after being explicitly closed and without being explicitly opened. Maybe there's a better name?

There's already a private implementation of CloseConnection(Async), which is fine, except we should allow an already-closed connection to be closed, and we need to respect AutoOpen and LazyOpen.

Add collections to parameters

DbParameters.AddMany(string name, IEnumerable values) could add parameters {name}_0, {name}_1, etc.

DbParameters.AddMany(Func<int, string> name, IEnumerable values) could allow the name to be customized, e.g. i => $"value{i + 1}".

Add collections of DTOs to parameters

Combining #7 and #8...

DbParameters.AddDtos(IEnumerable<object> dtos) could add PropA_0, PropB_0, ..., PropA_1, PropB_1, ...

DbParameters.AddDtos(string name, IEnumerable<object> dtos) could add a prefix, e.g. name_PropA_0, name_PropB_0, ..., name_PropA_1, name_PropB_1, ..., ...

DbParameters.AddDtos(Func<string, int, string> name, IEnumerable<object> dtos) could provide full customization of the parameter name.

Support prepared commands

If preparing a database command ever becomes useful, it would be simple to add a .Prepare() method to DbConnectorCommand that sets IsPrepared and calls .Prepare() on the actual command.

Support stored procedures

We should have a StoredProcedure overload for each Command method of DbConnector. It would work identically, except that it would set CommandType to StoredProcedure after creating the IDbCommand.

Support for casing options on Sql.ColumnNames

Sql.ColumnNames is great, but it would be nice if there were a casingKind option such that I could chose

• PascalCase
• camelCase
• nocase
• other?

Currently only snake_case is supported I believe?

Support automatic deadlock retry

A RetryDbConnector could retry operations on transient and/or deadlock exceptions.

This would work well with ExecuteTransaction (#46) but not with BeginTransaction etc. Should RetryDbConnector.BeginTransaction throw?

The settings should integrate well with Polly, ideally without taking a dependency on it.

Expose a Retry(Async) method that allows the caller to create their own retry units?

We would probably need protected overrides on DbConnector to which command operations would delegate so that we can retry queries.

Support automatic transaction commit

An ExecuteTransaction(Async) method could accept a delegate, begin a transaction, run the delegate, and commit the transaction. If the delegate returns a value, it could return that value.

Can we not commit the transaction if Commit or Fallback was called within the delegate?

This would be especially useful for a DbConnector that automatically retried deadlocks.