On 2016-03-05 19:00, Erik Smith wrote:
I'm definitely going to start working in async capability (or more accurately, non-blocking) into the interface. Both models are essential and there are strong use cases for both, but I know there is a lot of interest in NBIO for vibe.d compatibility. This is challenging and, as many are aware, the C clients for SQL databases have traditionally been synchronous only. One suggested approach is to fork the driver source and change the I/O calls to be non-blocking. Another is to implement a non-blocking driver directly against the wire protocol (a "native" driver). These are limited options, but to the extent this approach is viable in some cases (mysql-native for example), they could be adapted to a standard interface. The good news is that some databases do have (or are working on) non-blocking support in their C clients. The webscalesql mysql fork, for example, has a non-blocking client that is in production and their client works with regular mysql databases. That fork should eventually be merged back into mysql (or may have been already). Postgres also provides non-blocking support. These are two cases that I'm targeting for initial reference implementations.
Just for the record, there's already a native Postgres client that is non-blocking and vibe.d compatible. https://github.com/pszturmaj/ddb
-- /Jacob Carlborg
