The load works with mysql-router but will not work with mysql-proxy-rs and here is the error from our TPCC:

java.lang.RuntimeException: Error loading into table 'item' with SQL: INSERT IGNORE INTO `item` (i_id,i_im_id,i_name,i_price,i_data) VALUES (1,2816,'A6orZi0q5MGNmqNcMO',76.14,'k5LFMuM05JbY3ztNZa4Y5r8L0rU0VrpwVQpMPlP0g76MEVBspS'),(2,896,'Q78ZjbjJa3DJuUgWhZw',36.62,'aXQNsiRyGQZHJlNjgpLlWm2CpoSJR'),(3,9431,'7JZrAOnIHSVoYPwp1sLi',77.29,'Qo3aiqTrLLYutXg7NXb8YBo9cKSPyHHoOrJjWIcpsCjCRAIzmP')….( a lot more inserts here)
    at com.codefutures.tpcc.load.JdbcStatementLoader.executeBulkInsert(JdbcStatementLoader.java:72)
    at com.codefutures.tpcc.load.JdbcStatementLoader.load(JdbcStatementLoader.java:59)
    at com.codefutures.tpcc.Load.loadItems(Load.java:83)
    at com.codefutures.tpcc.TpccLoad.runLoad(TpccLoad.java:263)
    at com.codefutures.tpcc.TpccLoad.main(TpccLoad.java:334)
Caused by: com.mysql.cj.jdbc.exceptions.CommunicationsException: Communications link failure

The last packet successfully received from the server was 4 milliseconds ago.  The last packet sent successfully to the server was 2 milliseconds ago.

all the proxy says is this:

Failed to spawn future: Error { repr: Custom(Custom { kind: Other, error: StringError("connection closed") }) }

I'm completely new to rust so this could well be user error.

I've been playing around with the proxy example to mutate CREATE TABLE queries so that they will always have ROW_FORMAT=DYNAMIC appended if a row format is not already defined. The modified proxy example has been changed to

if sql.to_lowercase().starts_with("create table ") && ! sql.to_lowercase().contains(" row_format") {
    let new_sql = sql + " ROW_FORMAT=DYNAMIC";

    let mut payload: Vec<u8> = vec![];
    payload.extend_from_slice(&p.bytes[0..5]);
    payload.extend_from_slice(new_sql.as_bytes());

    let new_packet = Packet { bytes: payload };

    print_packet_bytes(&new_packet.bytes);

    Action::Mutate(new_packet)
}

When running a create statement such as CREATE TABLE test1 (id int); the printed bytes are correct (i.e. containing the extra appended ROW_FORMAT=DYNAMIC) but the application crashes with

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Error { repr: Os { code: 107, message: "Transport endpoint is not connected" } }', ../src/libcore/result.rs:799
note: Run with `RUST_BACKTRACE=1` for a backtrace.
error: Process didn't exit successfully: `target/debug/examples/proxy` (exit code: 101)

I can provide a back trace if required. Additionally the table does get created but without the ROW_FORMAT being set.

Is this something in the application or am I doing something wrong?

Hi so I am using your code to provide a mysql facade for postgres for a particular commercial product. Code works great thanks.

However, sometimes where I get the byte stream form said product I get

error: Utf8Error let sql = String::from_utf8(slice.to_vec()).expect("Invalid UTF-8");

How can I deal with this ? I'm not sure how non utf-8 can be sent.

Thanks

Caused by: failed to parse manifest at/home/$USER/.cargo/registry/src/github.com-88ac128001ac3a9a/openssl-sys-0.7.17/Cargo.toml`

Caused by: could not parse input as TOML /home/$USER/.cargo/registry/src/github.com-88ac128001ac3a9a/openssl-sys-0.7.17/Cargo.toml:45:9 expected a key but found an empty string /home/$USER/.cargo/registry/src/github.com-88ac128001ac3a9a/openssl-sys-0.7.17/Cargo.toml:45:9-45:10 expected ., but found '

`

If we hit an error during processing packets for a result set and then send an error packet to the client and drop the remainder of the result packets, the client terminates with a "Lost connection to MySQL" error.

The protocol documentation says that we should be able to do this. This needs further investigation, probably involving reading through the MySQL client source code.

We’re currently working with the base tokio-core crate, but would most likely benefit from moving up the stack to tokio-proto and potentially tokio-middleware.

Currently, the proxy maintains a one to one mapping of a client connection to a server connection. For more flexibility, the API should be extended so that the user-provided proxy logic can decide which MySQL instance to connect to. This would facilitate basic query routing and sharding.