Forum OpenACS Development: Re: nstcl vs. OpenACS db_* api
The only reason OpenACS has multiple pools (all to the same database, traditionally being main, subquery, and log) is due to the restriction in AOLserver that you have to allocate as many handles as you want upfront. Once you have allocated handle(s) you have to release them all before you can get more from the same pool.
I didn't feel any need to impose this restriction with nstcl. Rather, you can define a "pool" to have multiple connections and freely use them all up. In OpenACS if you have the standard 3 pools you can't nest more four-levels of db_foreach statements.
In nstcl, for any given pool (default or otherwise) you can have as many db_foreach statements nested as you have defined connections. With nstcl there really is no need to define multiple pools for any reason other than to connect to multiple databases, be they two different Oracle databases (production & development perhaps) or two completely different types of databases (Oracle & Postgres).
In this sense, a single nstcl "pool" encompases the main, subquery, and log pools of AOLserver. As for -dbn syntax; if that's the route OpenACS takes I'll likely add support to nstcl for it. Lately I've found myself using nstcl more for work utterly unrelated to (Open)ACS (and I regret I haven't had time to track and participate in OpenACS development), but since I'll be converting a site from ACS 4.2 to OpenACS shortly, it'll be time to catch up on things.
Hm, so the current workings of nstcl depend on the fact that all the drivers nstcl currently supports do not share AOLserver's "each thread must allocate all handles from a single pool at one time" limitation? So if down the road nstcl decided to support db drivers based on the AOLserver C code, you'd want to add in something like the db_nth_pool_name type stuff that OpenACS has?
On eventually adding the -dbn switch to nstcl, cool! I've yet to receive much of any feedback on it good or bad, but presumably others will gradually start using it. :)
Also, for the OpenACS db_* API, the -dbn switch definitely was the right way to go, but I don't see any harm in also adding your nstcl style "use this pool and no other" syntax, if people ask for it.