Query methods that accept byte slices (not just str)

[glittershark]

Oddly enough, it appears that MySQL is perfectly happy to accept queries that include invalid utf8 (eg for literals for blobs) - unfortunately, it's currently impossible to make those queries using mysql_async, since the query methods all accept &str. Would you be willing to accept a patch to add equivalent methods to query and prepare that accept &[u8] as well? Maybe query_bytes and prepare_bytes?

[blackbeam]

Sure. But I wonder can we make it without increasing the API surface e.g. using T: AsRef<[u8]≥.

[glittershark]

I'd be worried about that being a breaking change since AsRef<[u8]> + AsRef<str> is more restrictive than AsRef<str> Could introduce a new sealed trait for it (to accept either, but not require both), or just take the breaking change since mysql_async is 0.x anyway. Up to you.

[glittershark]

Speaking of breaking changes, adding these methods to Queryable is also a breaking change since it's not sealed - how do you feel about that?

[blackbeam]

Next release will be breaking anyway (because of changes in the LOCAL INFILE API).

[glittershark]

So would you rather go with AsRef<str> + AsRef<[u8]>?

actually that won't work (duh) since Vec<u8>, which is the type I want to supply, doesn't impl AsRef<str>

I started looking into this, and there are two options that feel good to me:

1. Just change everything to use AsRef<[u8]> instead of AsRef<str>. This is simple, and feels more "faithful" to the actual mysql native APIs, but is obviously going to be a pretty large breaking change for all clients, and is a little annoying at the call site if you've already got a String or &str since callers will have to call .as_bytes() on it.
2. Add a new AsQuery trait (bikeshed pending) to mysql-common which has impls for things like Vec<u8>, Box<[u8]>, etc, but also String, &str, Cow<str>, etc. This simplifies the call site for the "happy path", at the cost of a fair bit of additional complexity, plus requiring users to impl that trait (or worse, newtype+impl) if they were previously supplying queries as their own types that impl'd AsRef<str> (I'm thinking something like smallstr perhaps)

Thoughts? I lean towards option 1, but not strongly

[blackbeam]

Oh. I thought of just using AsRef<[u8]> instead of AsRef<str> but now I find the second option more preferable (actually because of Cow<str> that I use a lot).

I wonder how many users actually supplied their own types that impl'd AsRef<str> 🤔