Implement new async methods coming in .NET Core 3.0

[roji]

.NET Core 3.0 (and hopefully .NET Standard 2.1) will fill in some missing async APIs (e.g. transaction management), these should be implemented in MySqlConnector at some point.

dotnet/corefx#35012

[bgrainger]

• Add override ValueTask<DbTransaction> BeginDbTransactionAsync
• Add MySqlConnection.CloseAsync (Implement MySqlConnection.CloseAsync #467), MySqlConnection.DisposeAsync
• Add MySqlTransaction.DisposeAsync
• Add MySqlCommand.DisposeAsync
• Add MySqlDataReader.CloseAsync, MySqlDataReader.DisposeAsync

Open questions:

• Should new MySqlConnection.BeginTransactionAsync change to return ValueTask<MySqlTransaction>, or keep the return type as Task<MySqlTransaction>? It will always perform I/O.

[roji]

Should new MySqlConnection.BeginTransactionAsync change to return ValueTask, or keep the return type as Task? It will always perform I/O.

Since this is a provider-specific method, it ultimately depends on you.

First, are you sure the roundtrip-reducing optimization I described here is absolutely impossible with MySQL, and will never be possible? Because if the possibility exists it's definitely better to choose ValueTask now to avoid a breaking change later.

Even without this optimization, I'd lean towards leaving it to return ValueTask for consistency with the ADO.NET API. I suspect the extra overhead from ValueTask is going to be quite negligible for this specific method, which does a roundtrip - it may be best to simply benchmark this.

[bgrainger]

The (unstated) compatibility concern is with Connector/NET, which has exposed a (sync) Task<MySqlTransaction> MySqlConnection.BeginTransactionAsync() method for years, and which MySqlConnector currently clones.

The optimisation you mention may be possible by implicitly batching the START TRANSACTION; statement with the next statement the client executes. There would be some amount of complexity with doing that so I'm not planning to implement it soon.

[roji]

The (unstated) compatibility concern is with Connector/NET, which has exposed a (sync) Task MySqlConnection.BeginTransactionAsync() method for years, and which MySqlConnector currently clones.

Oh, I see, that makes some sense. If you're doing a major release and are willing to break this, it may be worth it to change to ValueTask - I'm not sure how important it is for you to be totally compatible with the Oracle provider. In any case the ValueTask/Task difference isn't huge for more scenarios - unless users are doing something more than awaiting (which may be rare with BeginTransactionAsync() specifically) there's no real difference - just a binary break that requires a recompile.

But if you really don't think you'll be doing the optimization it's just as well to leave it as is, I guess.

[bgrainger]

I'm not sure how important it is for you to be totally compatible with the Oracle provider.

Porting any code from Connector/NET to MySqlConnector requires (at minimum) a recompile, so a binary-breaking but source-compatible change is fine. After more thought, it seems best to align with ADO.NET here (even if it's not technically an override on most frameworks).

[bgrainger]

After all that, I didn't actually change the return type of BeginTransactionAsync (or add the necessary override).

[bgrainger]

The (unstated) compatibility concern is with Connector/NET, which has exposed a (sync) Task<MySqlTransaction> MySqlConnection.BeginTransactionAsync() method for years, and which MySqlConnector currently clones.

However, Connector/NET does not provide MySqlTransaction.CommitAsync or MySqlTransaction.RollbackAsync (not even with synchronous implementations), so continuing to be API-compatible with Connector/NET seems much less important.

[jadanah]

Just as a heads up the changes breaks compatibility with Pomelo.EntityFrameworkCore.MySql (v2.2.0) and will throw a runtime exception when SaveAsync is called on the ef core context.

MySqlConnector 0.57.0-beta3

MissingMethodException: Method not found: 'System.Threading.Tasks.Task`1<MySql.Data.MySqlClient.MySqlTransaction> MySql.Data.MySqlClient.MySqlConnection.BeginTransactionAsync(System.Data.IsolationLevel, System.Threading.CancellationToken)'.

[bgrainger]

I knew this would probably happen, since it is a binary breaking change. However, I hadn't coordinated with Pomelo yet. Just opened PomeloFoundation/Pomelo.EntityFrameworkCore.MySql#794 to track it.

[bgrainger]

@JoJo2406 I've pushed a preview release of Pomelo.EFCore that's compatible with the 0.57.0-beta series.

[jadanah]

Thanks Bradley,

I will test and let you know if I come across any issues.

[bgrainger]

Added in 0.57.0.