Re: Improving PDO persistent connections and event loop support

> But there is a reason why mysqli allows for this feature to be > switched off in the compilation options. Certain users do not like > this. I'm pretty sure this option introduced not by user demand. But because maintainers thought it may be useful. This should be opt in. Because backward compatibility, not because someone disliked it. Can't imagine situations where obtaining dirty connect from previous script execution would be useful. This may be implemented using pdo option: ```php $db = new PDO( 'dsn', 'user', 'password', [ PDO::ATTR_PERSISTENT => true PDO::ATTR_AUTO_RESET_PERSISTENT => true, ] ); ``` > It is silently discarding errors and data, which could be > disastrous in some situations. That's exactly what I want - not bothering about errors and data left from previous script. >> PDO does not have method for closing connection. > As I said in an earlier email, this is intentional. Such a method is > a bad idea. We have mysqli::close and this is ok. But PDO::close is a bad idea? I don't understand. > I stand by what I said before: in a well-designed > application, there is absolutely no reason to close the connection > explicitly. Creating well-designed application is hard. As a creator of event loop framework I can't be sure that every user of my framework is a superstar in programming and application design. So I'd prefer to leave my users with "crippled objects" that would fail-fast in the next loop iteration instead of invisible db connection leak. This is also very suitable for True Async RFC [1]. In that case if you want send queries in parallel coroutines, then db connection pool should be used. And for connection pool implementations it's mandatory to have possibility to close db connection explicilty. [1] https://wiki.php.net/rfc/true_async