Requesting async support

[sandersaares]

It would be desirable to use SM using async methods, e.g. migrator.MigrateToAsync(long), as the current synchronous style is rather limiting in this day and age.

[canton7]

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. Migrations are typically run when you're starting your application, and you can't do anything else until you've finished running them. Therefore if you call MigrateToAsync, you're freeing that thread to go and... do nothing - there's likely little other useful work it could be doing.

[sandersaares]

Migrations are typically run when you're starting your application, and you can't do anything else until you've finished running them.

As a counterpoint to this, my app does plenty of other things, such as reporting status, accepting connections and communicating with hosting infrastructure. Being able to perform asynchronous work greatly simplifies the mixing of all the different duties of my app.

I can understand the limitation if it is due to the data access layer in .NET not supporting async (not saying that is the case, though) but there does not seem to be any grounds in principle to avoid async.

[canton7]

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 Task.Run(migrator.MigrateToLatest).

I can understand the limitation if it is due to the data access layer in .NET not supporting async

I have moved to using DbConnection rather than IDbConnection as my connection base, so native async support is now available.

but there does not seem to be any grounds in principle to avoid async.

The trouble is, it's not simply a matter of adding async support in addition to the current sync support. At the end of all of my code is the migration that the user wrote. So either I have to make migrations synchronous, or asynchronous. Either the user has to write a void Up() method, or an async Task UpAsync() method. There's no sensible way of having both.

Therefore either SimpleMigrations is fully synchronous, or fully asynchronous.

If it becomes fully asynchronous, then:

1. Users have to always write asynchronous migrations.
2. It's different to every other migration framework out there, all of which are synchronous (as far as I know)
3. I break every existing user of SimpleMigrations.

I don't think this compares to supporting your use-case, which can also be handled by adding a simple Task.Run