Forum OpenACS Q&A: Problem upgrading oacs-5.8 to oacs-5.9

The script drops the tree_sortkey and max_child_sortkey columns from acs_objects and, given the use of 'cascade', also all the views making use of the two columns. I understand that this is necessary, but having some dozens of views to rebuild it's also quite annoying.

In my case I wrote a small before-upgrade script (luckily all my views share the same prefix) extracting the view definitions from pg_views, removing via regsub the two columns and saving them to a file that I then feeded to psql after the upgrade.

The trick worked except a single view calling the old tree_level function. I had to create a new orresponding function with a recursive query and I post the code here, in case it can be useful to anybody.

CREATE OR REPLACE FUNCTION tree_level(p_object_id integer)
  RETURNS integer AS $sql$                                                 
declare                                                  
   result  integer := null;                                                       
begin              

     with recursive objects as ( 
        select i.object_id, i.context_id
        from acs_objects i
        where i.object_id = p_object_id
        union
        select p.object_id, p.context_id
        from acs_objects p, objects s
        where p.object_id = s.context_id 
        )
	select count(*) into result
	from objects;

    return result;

end;$sql$
LANGUAGE 'plpgsql';

I installed Naviserver, PostgreSQL etcetera using the latest install-ns.sh script on a fresh Ubuntu 16.04.

First of all I upgraded the instance to the latest oacs-5-8-1, restarted the instance and verified that there were no errors in the error.log. Then I copied the 5.9.1 core packages over the 5.8.1 ones and tried to upgrade locally, but executing /acs-admin/apm/packages-install?operation=upgrade I got the following error:

no such key: word
    while executing
"nsv_get ad_page_contract_filters $filter"
    (procedure "ad_page_contract_filter_priority" line 2)
    invoked from within
"ad_page_contract_filter_priority $flag"
    (procedure "ad_page_contract" line 133)

It seems that ad_page_contract is broken. I then restarted the instance and retried but got the following from /acs-admin/install:

invalid command name "::xo::db::sql::site_node"
    while executing
"::xo::db::sql::site_node node_id -url /"
    invoked from within
"next "
    invoked from within
"ns_cache_eval xo_site_nodes id-$url { next }"
    (procedure ":get_node_id" line 2)
    invoked from within
":get_node_id -url $url"
    (procedure "get" line 10)
    invoked from within
"::xo::site_node get -url $url -node_id $node_id"
    (procedure "::nsf::procs::site_node::get" line 2)
    invoked from within
"site_node::get -url $url"
    (procedure "::nsf::procs::site_node::closest_ancestor_package" line 14)
    invoked from within
"site_node::closest_ancestor_package  -node_id [ad_conn node_id]  -package_key [subsite::package_keys]  -include_self  -element "node_id""
    (procedure "ad_conn" line 131)
    invoked from within
"ad_conn subsite_node_id"
    (procedure "ad_conn" line 135)
    invoked from within
"ad_conn subsite_id"
    (procedure "::nsf::procs::template::resource_path" line 8)
    invoked from within
"template::resource_path -type templates -style $style -relative"
    (procedure "template::themed_template" line 7)
    invoked from within
"template::themed_template [file rootname $relative_name]"
    (procedure "adp_parse_ad_conn_file" line 13)
    invoked from within
"$handler"
    ("uplevel" body line 2)
    invoked from within
"uplevel $code"
    invoked from within
"ad_try {
                $handler
            } ad_script_abort val {
                # do nothing
            }"
    invoked from within
"rp_serve_concrete_file [ad_conn file]"
    (procedure "::nsf::procs::rp_serve_abstract_file" line 60)
    invoked from within

Something must be changed from the last time I upgraded.

in my first attempt I copied the oacs-5-9-1 packages over a running oacs-5-8-1 instance and trying to upgrade I got the no such key: word error.

Then I restarted the instance, checked for errors in the error.log and found none of them and trying to upgrade I got the invalid command name "::xo::db::sql::site_node" error.

For some reason the ::xo procs were not available. Looking around I saw that the site-nodes-procs.tcl implements two versions of the procs based on the availability of the latest Xotcl.

I then set UseXotclSiteNodes to 0, restarted and all went well. The strange thing id that in the same environment the oacs-5-9-1 installed by install-oacs.sh script works perfectly well.

An old friend of mine used to say about programs: sometime they work, sometime not.

Making available the new xotcl-core solved the problem. Now I'm having some other problems, but I'll investigate before posting.

Many thanks for your help.

Claudio