cpdo  Artifact Content

Artifact c7ed5554f8d1e47df5a06e425a5f6d365f2efb77:

Wiki page [TODOs] by stephan 2011-05-17 18:39:28.
D 2011-05-17T18:39:28.531
P 7b2d217c5f065779fc66a103f1c88b2e977edb51
U stephan
W 3058
<strong>ACHTUNG: THE CPDO WIKI IS NOW (AS OF 2011-May-17) MAINTAINED ON A DEDICATED WIKI SITE:</strong> [http://whiki.wanderinghorse.net/wikis/cpdo/?page=TODOs]

Potential TODOs and other random thoughts:

   *  Several of the desired functions are not yet in the API, like get-affected-rows, and driver-level properties.
   *  Set up a more detailed/comprehensive test suite, stress test, and or "certification suite" which can be used to certify a given driver against the API's requirements.
   *  Clean up the build tree.
   *  Ongoing: wrap most the cpdo_stmt and cpdo_driver APIs into convenience functions, for code readability reasons.
   *  Add a 'get number of affected rows' feature to the API (e.g. for INSERT and DELETE statements). The problem with this is that some drivers implement it as a statement-level operation and some as a db-level operation. Statements can (with just a little effort on the driver implementor's part) keep a handle to their driver, so the instinct is to add this to the statement API. However, we then could not use this functionality from client code unless the client manually prepares the statement (as opposed to running it through <tt>cpdo_exec()</tt> or the like). Hmmm. We could also store it in the driver from the statement internals, but that has inherent threading-related problems.
   *  Most of the driver-level private state, other than the underlying db handle, which the driver impls currently hold has to do with the transaction-related APIs (they need to remember if they're in a transaction or not). Consider removing the transaction API so that we can allow those drivers to be multi-thread-capable as long as the underlying driver supports it.
   *  Add an optional client-defined mutex, similarly to what we do in the whalloc code. i'm not sure we can provide real locking safety without the client manually doing the locking/unlocking, though, due to the non-atomic nature of many db operation.
   *  Port the "sqlite3-to-JSON" converter to cpdo.

Other random thoughts:

   *  i still need to write "JSPDO", a JavaScript variant of PDO for the Google v8 JS engine. That idea was the initial inspiration behind this project (though a project at work finally got me in the mood to implement it).
   *  i think there are some really interesting possibilities for introducing a "JSON Db API", where the DBs only have to support the value types supported in JSON (they could simulate JSON booleans with integers). We could use an available JSON library ([http://fossil.wanderinghorse.net/repos/nosjob/|nosjob] and [http://fossil.wanderinghorse.net/repos/cson/|cson] both immediately come to mind) and wrap DB input/output values via those JSON-modeling APIs. Such a "lowest common demoninator" DB API, in conjunction with explicit JSON semantics, could have some interesting applications. And writing an ORM on top of that should be relatively simple. Such a frameworki would be easy to create on top of a combination of cpdo and [http://fossil.wanderinghorse.net/repos/cson/|cson].

Z 4eda9c7ad720c386b1e7130551334055