An all-D MySQL/MariaDB client library:

In v1.1.4:

Introduced auto-purge to fix a few problems.

- Fixed: #117: ResultRange cannot be copied. (@Abscissa)

- Fixed: #119: Is a defensive Connection.purgeResult call necessary before executing another statement? (As of this release, the answer changed from "sometimes" to "no") (@Abscissa)

- Fixed: #139: Server packet out of order when Prepared is destroyed too early. (@Abscissa)

- Change: MySQLDataPendingException (aka, MYXDataPending) is no longer necessary, and no longer thrown. When issuing a command that communicates with the server while a ResultRange still has data pending, instead of throwing, mysql-native now automatically purges the range and safely marks it as invalid and no longer usable. This was changed in order to fix #117, #119, and #139. This change should neither break user code nor require any changes. (@Abscissa)

- Change: Manually releasing a prepared statement is no longer guaranteed to notify the server immediately. In order to facilitate the above fixes, and avoid any nasty surprise with struct dtors triggering results purges implicitly, any release of prepared statements from the server is now queued until mysql-native can be certain no data is already pending. This change should neither break user code nor require any changes. (@Abscissa)

- Change: Prepared statements are no longer released automatically, due to the fix for #117. However, prepared statements and their lifetimes are tied to individual connections, and thus will die along with their connection, so manual release is not strictly necessary either. Accordingly, this change should neither break user code nor require any changes. (@Abscissa)

- Fixed: #143: Keep travis-ci build times under control by limiting the number of compiler versions tested on OSX. (@SingingBush)

Tentative plans for the next release (probably v1.2.0) include, among other things, removing the old deprecated APIs from pre-1.0, deprecating a few no-longer-needed things and some misc doc improvements.

Aside from those housekeeping details, my other next big priority is to finally tackle the awkwardness of combining prepared statements with connection pools. MySQL itself ties prepared statements to the individual connection that created them, and that's caused difficulties for connection pool users. So I'm thinking a connection-independent abstraction is warranted for prepared statements.

Mysql-native is made for its users, so if an issue is particularly pressing for you that you feel has been neglected, vote for your biggest bug-a-boo by pinging it:

(Or better yet, contribute!)

Reply via email to