cpdo

cpdo_mysql5
Login

ACHTUNG: THE CPDO WIKI IS NOW (AS OF 2011-May-17) MAINTAINED ON A DEDICATED WIKI SITE: http://whiki.wanderinghorse.net/wikis/cpdo/?page=cpdo_mysql5

The MySQL driver binding was a bitch to implement, but appears to work as expected and supports all features required by the cpdo interface. In my tests it is, for reasons i cannot explain, notably faster than cpdo_sqlite3. (Weird!)

This driver was developed with MySQL v5 (i believe it needs 5.0.3 or higher), and might or might not compile as-is on newer or older versions. If it does not, please report it (but i have no intention of back-porting to MySQL v3 if it's a major hassle to do so).

The DSN format for this driver is "mysql5:option1=value1;option2=value2...". The supported options are:

Compatibility Notes:

Bugs:

Potential TODOs:

Binding Parameters by Name

As mentioned above, MySQL 5.x does not natively support binding parameters by name. So we had to hack together a solution (and i'm quite satisfied with it, actually). The parser for doing this is hand-written and not terribly complex, but is believed work error-free on any input which itself is valid SQL. Since invalid SQL will not be accepted by the driver anyway, mis-parsing in such cases is probably not going to cause any additional problems. (The support is also generic, so that it can be re-used in other driver implementations if we need it.) It will produce undesired results when given weird driver-specific SQL which itself uses colon characters.

Here are some notes to explain areas which might not be intuitive...

Achtung: this driver does not allow a parameter name to appear more than once in a given statement. Doing so will result in binding only the first instance of that parameter when binding by parameter name. The underlying SQL driver might notice that no value was set for that parameter and give us a useful error message, but it might also misbehave.

Mixing named- and non-named parameters:

Consider this SQL code:

INSERT INTO T VALUES( ?, :param2, :param3, ? )

i have NO idea how drivers normally handle (or not handle) mixed-type usage like this, but this driver does the following:

To get MySQL to swallow the SQL we have to translate the parameter name parts (:param2 and :param3) to a ?. As a side effect of this the named properties are at index positions 2 and 3 (remember that bind parameters use 1-based indexes). To see why, consider that the above SQL is internally translated into:

INSERT INTO T VALUES( ?, ?, ?, ? )

The driver then remembers the names and index positions of each named parameter so that calls to stmt->api->bind.param_index(stmt,":param2") will (in this case) return 2.