Why is this package not based on mysqli?

[BenMorel]

First of all I'm sorry as this is not really an issue, but I got curious and StackOverflow closed my question as off-topic, so I thought I'd ask here directly:

Why isn't amphp/mysql based on mysqli?

mysqli supports async queries, so was there a reason why this library was not simply built of top of mysqli, instead of re-implementing the whole MySQL protocol?

Thanks for your time!

[bwoebi]

mysqli_poll() is just polling ... mysql. It does not provide you any possibility to poll any other streams together with the mysql data.
There's no underlying file descriptors exposed by mysqli which the event loop could use.

[BenMorel]

Thank you for the explanation! 👍 This makes perfectly sense now.

[dbalabka]

@bwoebi am I right that MySQLi should some function like \pg_socket to provide access to connection socket?
https://github.com/amphp/postgres/blob/master/src/PgSqlConnection.php

If so, it might be reasonable to propose missing functionality via RFC into PHP Core. IMO MySQL support is crucial for async support. In contrast with recently implemented Fibers, it might give opportunity for adopting Amp into projects via such popular DBALs like Doctrine.

[bwoebi]

No, you are not right. The issue is at the protocol level. The mysql protocol does not allow for multiple queries executing at the same time on a single socket. Which why we are using connection pooling.

[kelunik]

@bwoebi one query per connection is fine, an exposed socket would still be useful to avoid the userland protocol implementation.

[dbalabka]

@bwoebi the reason why I'm asking is that recently I've found that MySql 8 client library supports async queries:

https://dev.mysql.com/doc/c-api/8.0/en/c-api-asynchronous-interface.html

Does it might mean that MySQL protocol supports async queries now?

[dbalabka]

Answering my previous question. Obviously, MySQL binary protocol is sync, so nothing changed, the C client just works with the connection pool.