A complete wrapper is not feasible: How to implement "ns_db gethandle" on top of the dbi driver, if there is no handle available at the Tcl level? And how useful will such an emulation be?
Unfortunately OpenACS has quite a wide SQL interface, with sometimes complex interactions (e.g. nested db_foreach with transaction management). Making a bug-compliant replacement is quite hard, some of the used constructs are not recommended for many of the usages but often convenient (db_foreach), so piling layers don't look optimal to me. And i don't know, who would volunteer to make this work.
However, if the wrapper doesn't have to be 100% compliant, some wrappers can be certainly be provided. But in general it looks more ´feasible to me to use higher abstractions and to work towards higher abstractions where these do not exist. For example, the xo::db::sql interface generates on the fly the calls to stored procedures differently for Oracle and PostgreSQL. So, one could easily make use of the dbi interface with little code without loosing oracle compliance. The xo::db::sql interface can be potentially used in many places, but unfortunately, not all of the code in OpenACS uses this interface (essentially just the xo* packages).
I've prototyped a dbi interface for xo::db::sql just now. Here is a quick implementation for permissions, using the xo::db::sql interface.
ad_proc -private ::permission::permission_p_not_cached {
{-no_cache:boolean}
{-party_id ""}
{-object_id:required}
{-privilege:required}
} {
does party X have privilege Y on object Z
@see permission::permission_p
} {
if { $party_id eq "" } {set party_id [ad_conn user_id]}
::xo::db::sql::acs_permission permission_p -object_id $object_id -party_id $party_id -privilege $privilege
}
The definition is about twice as fast as the actual OpenACS implementation on my machine when i am using the dbi interface (the sql prepare statement does not help at the same degree as other places, since the actual call is quite short). Note this this definition is compatible with Oracle as well (no .xql files needed). The only blocker is that we have currently acs-core xo*-free.
Also, many other parts of xotcl-core could be relatively easy developed further to support both the classical and the new dbi interface, at least xowiki and xowf and derivatives would benefit from this.
Another place with a common abstraction and potential larger reuse is db_multirow; many code pieces could benefit if there would be a dbi-compliant version of this function.
