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_sqlite3
The sqlite3 driver binding is basically the reference implementation. It supports the cpdo interface requirements to the letter and supports all of the optional features.
The DSN format for this driver is "sqlite3:filename", where filename must be a relative or absolute path do a database file or the special name :memory: for an in-memory database. The database will be created if it does not yet exist (and "connecting" will fail if it cannot be created). This driver ignores any username/password provided for connecting.
Required sqlite3 Version: the oldest version i have tested was 3.3.6 (released in June 2006). Normally i develop using whatever version is on my Ubuntu boxes (which run system updates every few days), and occasionally (but not often) try out older versions.
- Add DSN attribute "failifnotexists=boolean" (or something like that) so the caller can require that the DB already exists. By default sqlite3 creates the db if it does not already exist.
Notes about Overhead
The overhead imposed by this driver, over using sqlite3 directly, is minimal.
i have two nearly-identical test apps in one project which differ only in their db driver: one uses cpdo (with sqlite3 as the back-end) and one uses the sqlite3 API directly. For that particular test app (it's very small), the total memory costs were:
- sqlite3: 389 allocations totaling 212480 bytes.
- cpdo/sqlite3: 400 allocations (diff=+11) totaling 212808 bytes (diff=+328).
The majority of that memory (somewhere in the neighborhood of 200kb) is allocated by sqlite3 itself, but the JSON library used by the test apps is the source for many of the allocations (but only a few kb of memory).
The "extra" allocations we see in the cpdo-using app are primarily in the form of the cpdo-level wrapper classes for the underlying db and statement handles.