Forum OpenACS Development: Proper config.tcl for mixed-DB server?

1: Proper config.tcl for mixed-DB server?

Posted by Dave Hill on 09/28/01 11:05 PM

How does one include or exclude pools for use by OACS4? This is of course critical for any integration with or migration from other tcl db apps, including ACS Classic and OACS 3.2. I'm running into this with the bboard migration pages.

The comments in the db api code imply this is possible, by setting the "AvailablePool" parameter(s) to only the ACS ones. However, I can't find any reference to that name in the aolserver config reference. Is AvailablePool set by "ns/server/$servername/pools"? If so, how do you exclude pools from the ACS?

BTW, long term, I second Michael's suggestion for a -database or -pool flag in the api, as mentioned at the end of this thread

2: Response to Proper config.tcl for mixed-DB server? (response to 1)

Posted by Tom Jackson on 09/28/01 11:33 PM

The following is from packages/acs-tcl/tcl/10-database-procs.tcl, but it is commented out along with the procs that used this. If you use an older version of ACS this will work, but you have to put one line for each pool, including main, subquery and log.

#
# This list is defined in the [ns/server/yourserver/acs/database] section using the key
# AvailablePool=foo (one line per pool).
#

3: Response to Proper config.tcl for mixed-DB server? (response to 1)

Posted by Tom Jackson on 09/28/01 11:39 PM

I just found this in the same file: 10-database-procs.tcl

#
# Initialize the list of available pools
#

global apm_first_time_loading_p
if { [info exist apm_first_time_loading_p] && $apm_first_time_loading_p } {
    set server_name [ns_info server]
    append config_path "ns/server/$server_name/acs/database"
    set the_set [ns_configsection $config_path]
    set pools [list]
    if {![empty_string_p $the_set]} {
	for {set i 0} {$i < [ns_set size $the_set]} {incr i} {
	    if { [ns_set key $the_set $i] ==  "AvailablePool" } {
		lappend pools [ns_set value $the_set $i]
	    }
	}
    }
    if { [llength $pools] == 0 } {
	set pools [ns_db pools]
    }
    ns_log Notice "Database API: The following pools are available: $pools"
    nsv_set db_available_pools . $pools
}

It looks like you could dynamically set the available pools. To add a new pool to the list, to the end:

nsv_lappend db_available_pools . $pool

4: Response to Proper config.tcl for mixed-DB server? (response to 1)

Posted by Dave Hill on 09/29/01 12:07 AM

Thanks. To be clear, here's a snippet of a working mixed-db config, with the pools renamed more logically. ("main", "log", "subquery" have no relation to their use any more).

ns_section "ns/db/pools" ns_param oacs_1 "OpenACS.org depth 1 pool" ns_param oacs_2 "OpenACS.org depth 2 pool" ns_param oacs_3 "OpenACS.org depth 3 pool" ns_param other "Some Other DB Pool" ns_section "ns/server/${server}/acs/database" ns_param AvailablePool "oacs_1" ns_param AvailablePool "oacs_2" ns_param AvailablePool "oacs_3" But then make sure you rename each ns/db/pool/[poolname] section!

Oh, and indeed you could do it on the fly, but then you'd have to do it every time before every use, so that it survived restarts.

5: Response to Proper config.tcl for mixed-DB server? (response to 1)

Posted by Andrew Piskorski on 09/29/01 02:19 PM

Dave, I've already implemented the idea of a "-database" flag to the DB API for ACS 4.2. (I called the flag "-dbn", for "database name".) I've been using it for nearly a month now and it seems to work fine. But, I haven't had the time yet to try implement the same for OpenACS. (Also, although I haven't shown anybody the code, it seems that Don may not like it.)

Anyway, it just involves changes to three files in packages/acs-tcl/tcl/ : table-display-procs.tcl, 10-database-procs.tcl, and database-util-procs.tcl

If you want to look at the code, I've slapped those files into a folder called "DB-API - Multiple Databases" in the Shared OpenACS Community document tree. E.g., ReadMe.txt and 10-database-procs.tcl.

(Btw, I tried sticking them into my personal file storage area, but the new-file-storage permissions UI seems to be so broken that there's no way for me to let anyone else see the files there.)

6: Response to Proper config.tcl for mixed-DB server? (response to 1)

Posted by Don Baccus on 10/01/01 01:08 AM

I only explained why we choose to avoid the "switch" statement approach,
and suggested that you use the bootstrap/installer multi-db support for your efforts to provide an ODBC/DB2 API within the OpenACS realm.

Talking to multiple RDBMS via the db api would be nice. It doesn't make
sense to talk of an OpenACS installation split across multiple brands of
RDBMS IMO, so this capability is *far* from near the top of any reasonable priority list. After all, you can use ns_db and a pool pointed to the foreign db with no problem, and any such code is going to be in the form of customized additions to your OpenACS installation anyway. Most folks will never have the need for an extended db api, and those that need it have a workaround in the form of the AOLserver ns_db api which is not at all bad, after all...

7: Response to Proper config.tcl for mixed-DB server? (response to 1)

Posted by Andrew Piskorski on 10/01/01 10:00 AM

Don, I agree that a multi-db DB API is a nice-to-have but not critical
feature for OpenACS.

"Splitting" an OpenACS installation across different types of RDBMS,
well, yeah, I can't even imagine a situation where that would make
sense. But some folks might need to write a particular application to
use a secondary database for some functions, and being able to use the
same ACS DB API for that is very nice.

As for the switch statement vs. bootstrap/installer stuff, I have my
own opinions about that (surprise surprise), but I haven't looked into
the bootstrap/installer stuff for OpenACS yet, so I can't say anything
else useful about it at this point.

8: Response to Proper config.tcl for mixed-DB server? (response to 1)

Posted by Don Baccus on 10/01/01 07:01 PM

Well ... we're highly unlikely to change our approach at this point, now that several hacker-months (years?) have gone into porting code with the existing paradigm...