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

Overview of cpdo

cpdo modeled very heavily off of the PHP PDO API. PDO has become my favoured DB abstraction API over the years, and i wanted something similar for C++, to add to the Google V8 JavaScript engine. But i wanted it in C.

The primary classes are:

Each of those classes has member function whose behaviours are documented by the cpdo interface, but whose implementations are driver-specific. Features which do not need driver-specific details to work are provided in the form of non-member functions. (Many of the member functions are also available via non-member interfaces, for code readability reasons - some people prefer foo(x) over x->api->foo(x)).

Guiding Principals

The guiding principals of this project include:


The core library knows, of course, nothing about any specific database server. That's where "drivers" come in. Each db back-end requires a driver, which is a cpdo_driver instance customized to work with that back-end. It is those drivers, and only those drivers, which create cpdo_stmt objects on behalf of the client.

The sqlite3 driver is used for the core development (because it's just so damned easy to use), and cpdo's sqlite3 driver supports the cpdo interface requirements to the letter.

The MySQL driver proved to be much more difficult to implement because of MySQL's truly odd requirement of making client code manually manage all input/output values, including their allocation, deallocation, and cryptic setup. In terms of code lines, the MySQL driver requires almost about 2.5 times as much code as cpdo_sqlite3, plus i had to add additional internal infrastructure in the core library to be able to support MySQL's buffering requirements.

It would be cool to wrap up ocilib, and i have access to a machine i could do that from, but i don't want to have to sit in the office late at night to work on this (that's where the machine is).