Support for std::future and async/await

[pimeys]

std::future is now in 1.36.0 and async/await is going to (hopefully) be stabilized in 1.38.0. Opening up this issue to track progress on upgrading mysql_async to the new syntax.

Is anybody working on this already? We might be able to put some hours to the refactoring in Prisma later on.

[pimeys]

I'd say it would be a good goal to change the Queryable to take reference in its functions. Would make it much easier to abstract with other databases, such as PostgreSQL.

[pimeys]

Tokio master is getting close to the alpha release of std::futures refactoring. mysql_async needs the tokio-uds crate that still has some work to do, but there's a pull request already.

tokio-rs/tokio#1227

tokio-named-pipes for Windows support needs to be refactored by somebody with a Windows computer.

[pimeys]

Spent the day to at least get the types right. I guess I'll be working on this at least for now...

https://github.com/pimeys/mysql_async/tree/async_await

[pimeys]

So spent a couple of days to see how much work it would be to have Client/Transaction taking &self instead of self and upgrading to the std::future. Noticed the architecture should change into something similar what tokio-postgres is doing and decided it would take too much time now for me to try changing this crate.

[jonhoo]

@blackbeam do you think this is something you'll have the spare cycles to take on any time soon?

[pimeys]

Some learnings from those two days of work I did a couple of months ago, and reading what @sfackler has done in the std-futures branch in tokio-postgres:

• Internally use a oneshot channel to create a future. Then in cases like transactions, when dropped the transaction can still be rolled back without having an executor available in Drop.
• The codec is a great idea, same for the common types.
• The sync mysql crate is a much easier starting point than this one.
• Lots of work, especially with the AsyncRead/AsyncWrite conversion
• Most of the work is just adding Pin, but certain features are now missing in the new futures and need to be redesigned completely.

[jonhoo]

I'm doing a very direct port over at #71. I'm avoiding rearchitecting as much as I can, and instead doing a mostly mechanical transformation. Seems to be going okay so far, but I'm not quite done yet (need tokio-rs/tokio#1537 for example). There are definitely a bunch of places the codebase could be improved (in particular, a bunch of Boxes that could be removed), but at least this will get us off the ground.