Antony Male

I had a look at this. Some notes on some of the complexity that needs to be worked through: 1. I want to make this work similarly for QueryMap and...

Not going to happen, I'm afraid, for the following reasons: 1. No migration framework that I know of makes you write `Task UpAsync()` and `Task DownAsync()` on your migrations. 2....

> Being able to perform asynchronous work greatly simplifies the mixing of all the different duties of my app. From that perspective, I don't see the difference between `migrator.MigrateToLatestAsync()` and...

See #12. This always breaks backwards compatibility in quite a big way I'm afraid, so it's a no-go. What exactly is your problem? Is ServiceStack.OrmLite giving you an IDbConnection, which...

Since I give the user a reference to the IDbConnection in the migrations, I give them the ability to use the new methods which have been added since the concrete...

I would still like to understand your use-case though: is the problem that ServiceStack is creating your DbConnection for you, and you want to preserve that? Also, it looks like...

>> since the concrete classes replaced the interfaces. > > Can you expand on this? My understanding is that the interfaces (IDbConnection, etc) were introduced first, then Microsoft hit the...

> But I still fail to see the benefit of using the concrete classes (apart from backwards compat with older Simple.Migrations). The interfaces are a part of .NET Standard, and...

Your final option of course is something like this: ```csharp public class ProxyDbConnection : DbConnection { private readonly IDbConnection dbConnection; public ProxyDbConnection(IDbConnection dbConnection) { this.dbConnection = dbConnection ?? throw new...

> I think ServiceStack.OrmLite and Dapper got it right. Use IDbConnection, and cast to DbConnection if you need a newer method. But that just moves the problem to runtime! If...