Forum OpenACS Development: Re: nsdbi, nsdbipg
- dbi_* has no -dbn, but "-db" in dbi-* is probably wrappable
- dbi_* has no -cache_key and -cache_pool
- the option "-bind" is probably sufficient compatible
- the db_* option "-column_array" is probably sufficient compatible with the differently named "-array" in dbi_*
- the db_* option "-column_set" is not documented, but reading from the source, this is not implemented in dbi
- the dbi_* option "-timeout" is not available for nd_db
- the dbi_* option "-db" is not available for nd_db
- the dbi_* interface has no .xql support
- the developer support output is missing for dbi, so
one needs here as wrapper or some sandwiching;
wrapper require uplevel-ing for bindvars.
- dbi* has no full sql statement (with variables substituted), since there is no such thing in dbi
- Interactions with the db_* transcation management are not clear for me, for reading operations, that should not be an issue worse that the current situation
Many of the mentioned options are seldomly used, the developer support should be done anyhow, some more issues will popup probably.
If one overwrites the two db_* functions by a version based on dbi, this "wrapper" function has to support all features used in any obscure niche in OpenACS. Furthermore, one has to install in the long range both drivers in OpenACS, since the hope to make the code fully compatible is very little. Therefore if one "recommends" to install both drivers, the code becomes harder to maintain and to test.
By moving towards higher abstractions, one has more freedom in the implementation, one can mark lower-level access as deprecated and there is a clear development direction. Also, XOTcl's mixins could be used as an extension mechanism not requiring to overwrite existing functions physically.
Antonio, what are your concerns about using ::xo::db::sql in the core? The interface and implementation is rock-stable, these functions are used in the largest OpenACS sites, xotcl is a requirement of every OpenACS installation, all the contributors of the last two years are knowledgeable in xotcl.
all the best
I fully trust xotcl api, and think it gives advantages to developers, mainly related to flexibility and code reuse, but is also a different paradigm, requiring quite some cognitive load to people used to current codebase (here in Italy, most of the programming I've seen was procedural). Of course, this is not a big problem if changes happen "under the hood" in the api.
This said, it is right to move on when this gives improvement for performances and capabilities. xotcl-core is out there since a while now, so eventually a wider adoption into core codebase needs to be considered.
The total performance improvement as measured with a small instance by the developer support is more than 20%, which is quite good. To make the migration easier, i've extended the nsdbi module; not sure whether all my changes should go into the nsdbi module.