FetchAsync with MySqlDataReader

[RicardoCampos]

This isn't an issue with your code per se, but might be worth noting in the Readme. The current MySql driver (6.9.5 at the time of writing) and presumably all before it does not implement it's *Async methods asynchronously, but completely synchronously. So, yes it works for MySql, but not asynchronously.

Personally, I'd have preferred if they threw a NotImplementedException instead. You can get round this by wrapping it with Task.FromAsync, but it would mean doing lots of if (IDbReader is MySqlDataReader) style checks, which would be messy. Here's an example wrapper as an extension method, just FYI really.

public static class MySqlCommandExtension
{
    public static Task<MySqlDataReader> MyExecuteReaderAsync(this MySqlCommand source, CommandBehavior behavior = CommandBehavior.Default)
    {
        return Task<MySqlDataReader>.Factory.FromAsync(source.BeginExecuteReader(behavior), source.EndExecuteReader);
    }
}

[tmenier]

Sorry I never responded. Do you know if this is still the case? I'm guessing so, otherwise I think questions like this would be updated:

http://stackoverflow.com/questions/21978629/does-net-4-5s-async-feature-work-with-mysql-and-other-databases-too

Do you think there's any reason to support MySQL in AsyncPoco at all? If the driver lacks true async support, then I think PetaPoco (or another ORM with sync support) should be used. I don't want the library to give the impression that something is async when it is not.

[bgrainger]

I've authored an alternative ADO.NET connector for MySQL that is fully asynchronous: https://github.com/mysql-net/MySqlConnector

I've opened #36 to switch to it, which would allow this issue to be closed, since AsyncPoco can now offer a truly asynchronous API for MySQL.

[tmenier]

Actually this should work fine with no changes to AsyncPoco. As long MySqlConnector is installed with the client app and the connection string is configured to use it, it'll leverage that provider. So although not a direct concern of AsyncPoco, I think just the fact that a truly async provider exists closes this issue.

Thanks @bgrainger!