Forum OpenACS Q&A: Re: Res: Re: Lazy site node caching

Simple answer: .LRN sucks. More correct answer:

.LRN makes use of the NSV Array directly. I fixed the issues during startup, but the fact remains that .LRN has rewritten site nodes in dotlrn/tcl/site-nodes-procs. These procedures should not be in the .LRN package in the first place. But they are there and I don't have the time (neither the client the budget as he isnt using .LRN) to fix this at the moment.

Here is the fix for .LRN initialization

===================================================================
RCS file: /cvsroot/openacs-4/packages/dotlrn/tcl/applets-procs.tcl,v
retrieving revision 1.20
diff -r1.20 applets-procs.tcl
38c38
< if {[nsv_exists site_nodes "[get_url]/"]} {
---

if {[site_node::get_node_id -url "[get_url]/"] ne ""} {

Index: tcl/dotlrn-procs.tcl
===================================================================
RCS file: /cvsroot/openacs-4/packages/dotlrn/tcl/dotlrn-procs.tcl,v
retrieving revision 1.75
diff -r1.75 dotlrn-procs.tcl
108d107
< FIXME: refactor
110,122c109,115
< set dotlrn_ancestor_p 0
< set package_list [nsv_array get site_nodes "[get_url]/${package_key}*"]
<
< for {set i 1} {$i < [llength $package_list]} {incr i 2} {
< array set package_info [lindex $package_list $i]
<
< if {[site_node_closest_ancestor_package -default 0 -url $package_info(url) [package_key]] != 0} {
< set dotlrn_ancestor_p 1
< break
< }
< }
<
< return $dotlrn_ancestor_p
---

set site_node [site_node::get_node_id -url "[get_url]/${package_key}/"]
if {$site_node eq ""} {
return 0
} else {
return 1
}

package_id_from_package_key makes a round trip to the site node cache to figure out the package_id. Not sure why, but thats how it is. You can easily circumwent this by changing the way xotcl requests the package_id or by running site_node::update_cache with the node_id of the object = package_id from the request processor on initialization of the request processor.

I dont have a checkout of LORSM from 5.2, but in HEAD I could not find anything which could cause this behaviour. If you could specify the error a little bit larger (not only this message but the whole text from the error log) then i might be able to help more.

In general there should be no direct nsv call to the site node. In HEAD it is done using site_node::get_url_from_object_id and this should work just fine (at least the procedure should be unable to fail), but maybe you have a culprit there.

THis is excellent news Agustin. If you have the time maybe you can patch the file in CVS HEAD directly and upload it? This would be great.

.LRN Honchos. Is it okay to include the patch above in 5.3 or should I only commit this to the HEAD version of .LRN?